This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Fix new AMQP Transport test with Envelope & fix contract
| Q | A
| ------------- | ---
| Branch? | 4.1 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | https://travis-ci.org/symfony/symfony/jobs/377246434#L3685-L3686, https://ci.appveyor.com/project/fabpot/symfony/build/1.0.36261#L297 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Commits
-------
7223bd75f9 [Messenger] Fix new AMQP Transport test with Envelope
This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Fix return senders based on the message parents/interfaces
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
c3d4536203/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php (L1494-L1499)
According to the code a message interface is supported into routing configuration, but it doesn't work when `SendMessageMiddleware` gets the mapping senders for the current object message.
This PR tries to fix it.
Commits
-------
41e25abf8c Fixed return senders based on the message parents/interfaces
This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Add more tests around the AMQP transport
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
Adding more tests to the AMQP transport/factory. These should have captured the following 3 bugs: #27198, #27197, #27196.
Commits
-------
faf9382223 Add more tests around the AMQP transport
This PR was squashed before being merged into the 4.1 branch (closes#27200).
Discussion
----------
[Messenger] Make sure Sender and Receiver locators have valid services
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This make sure that Sender and Receiver locators have valid services. Also adds minor improvements into consume command.
Commits
-------
301ce5f839 [Messenger] Make sure Sender and Receiver locators have valid services
* 4.1:
[Messenger][DX] Uses a default receiver when only one is defined
fix deps
[Profiler] Join using ';\n'
Rename the command `DebugCommand`
[Messenger] Add debug:messenger CLI command
[Messenger] Fix default bus name
Fix the transport factory after moving it
[Messenger] Fix AMQP Transport factory & TransportFactoryInterface
Fix AmqpTransport
[Profiler] Fix dump makes toolbar disappear
Improved exception on invalid message type
bumped Symfony version to 4.1.0
updated VERSION for 4.1.0-BETA1
updated CHANGELOG for 4.1.0-BETA1
[Messenger] Add TransportInterface as first class citizen sender+receiver
This PR was squashed before being merged into the 4.1 branch (closes#27203).
Discussion
----------
[Messenger][DX] Uses a default receiver when only one is defined
| Q | A
| ------------- | ---
| Branch? | 4.1
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
When using only one receiver, as a developer, it makes no sense for me to have to precise the receiver name when using the `messenger:consume-messages` command. This is the change:
```patch
- bin/console messenger:consume-messages default
+ bin/console messenger:consume-messages
```
If I have more than one transport configured, I'll get the following message:
>
> You have 0 or more than one receiver (no default have been found). You need to specify the receiver name with an argument.
>
Commits
-------
8315b868d5 [Messenger][DX] Uses a default receiver when only one is defined
This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Add debug:messenger CLI command
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #... <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs#... <!-- required for new features -->
Adds a `debug:messenger` CLI command to expose message classes that can be dispatched. Heavily inspired by `debug:autowiring`.
Commits
-------
7f87309c10 fix deps
290c7eb1bc Rename the command `DebugCommand`
9847b83723 [Messenger] Add debug:messenger CLI command
This PR was merged into the 4.1 branch.
Discussion
----------
[Messenger] Fix AMQP Transport factory & TransportFactoryInterface
| Q | A
| ------------- | ---
| Branch? | 4.1 <!-- see below -->
| Bug fix? | yes
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | #27164 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Seems like we did review a bit fast here 😅
Commits
-------
98967cd73a [Messenger] Fix AMQP Transport factory & TransportFactoryInterface
This PR was squashed before being merged into the 4.1-dev branch (closes#26945).
Discussion
----------
[Messenger] Support configuring messages when dispatching
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | see CI checks <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | todo
For now, this is mainly a RFC to get your opinion on such a feature (so it misses proper tests).
Supporting wrapped messages out-of-the-box would mainly allow to easily create middlewares that should act only or be configured differently for specific messages (by using wrappers instead of making messages implements specific interfaces and without requiring dedicated buses). For instance, I might want to track specific messages and expose metrics about it.
The Symfony Serializer transport (relates to #26900) and Validator middleware serve as guinea pigs for sample purpose here. But despite message validation usually is simple as it matches one use-case and won't require specific validation groups in most cases, I still think it can be useful sometimes. Also there is the case of the [`AllValidator` which currently requires using a `GroupSequence`](https://github.com/symfony/symfony/pull/26477) as a workaround, but that could also be specified directly in message metadata instead.
## Latest updates
PR updated to use a flat version of configurations instead of wrappers, using an `Envelope` wrapper and a list of envelope items.
Usage:
```php
$message = Envelope::wrap(new DummyMessage('Hello'))
->with(new SerializerConfiguration(array(ObjectNormalizer::GROUPS => array('foo'))))
->with(new ValidationConfiguration(array('foo', 'bar')))
;
```
~~By default, Messenger protagonists receive the original message. But each of them can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`.
Then, they can read configurations from it and forward the original message or the envelope to another party.~~
Senders, encoders/decoders & receivers always get an `Envelope`.
Middlewares & handlers always get a message. But middlewares can opt-in to receive the envelope instead, by implementing `EnvelopeReaderInterface`.
Commits
-------
749054a1e8 [Messenger] Support configuring messages when dispatching
This PR was merged into the 4.1-dev branch.
Discussion
----------
Rename middlewares to middleware
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | n/a
| License | MIT
| Doc PR | n/a
`middleware` is uncountable in English (like software or information). So, I've removed the `s` everywhere. We can probably be a bit more explicit if we think it makes thing easier to understand like I've done in one class, like `middlewareHandler`.
Commits
-------
9ae7c11805 Do not fix the `middleware` XML name anymore
52e7500edb removed usage of middlewares
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Add missing `@experimental` annotations
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
So we have all the Messenger interfaces tagged with `@experimental`.
Commits
-------
7f875cb52b Add missing `@experimental` annotations
This PR was squashed before being merged into the 4.1-dev branch (closes#27129).
Discussion
----------
[Messenger] Rename Adapters to Transports
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
Last of our tasks on the "plan to beta", renaming "adapters" to "transports". This is a term that makes more sense and is commonly used within the "queue community".
Commits
-------
13b747565f [Messenger] Rename Adapters to Transports
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] unwrap ReceivedMessage in LoggingMiddleware to improve log detail
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
The change gives better visibility in your logs when consuming messages.
Commits
-------
78bb0252b4 [Messenger] unwrap ReceivedMessage in LoggingMiddleware to improve log detail
This PR was squashed before being merged into the 4.1-dev branch (closes#26864).
Discussion
----------
[Messenger] Define multiple buses from the `framework.messenger.buses` configuration
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #26652
| License | MIT
| Doc PR | https://github.com/symfony/symfony-docs/issues/9617
Not everybody will benefit from having only one bus, especially with the CQRS-like usages. While keeping the extremely use of use of the single bus, this PR has the following:
- Create multiple buses from the YAML configuration
- Tag middleware only a specific buses
- Register middlewares from the YAML configuration
Even if it's visible in the PR's tests, here's how it will look like, for a completely full-customised version:
```yaml
framework:
messenger:
default_bus: commands
buses:
commands: ~
events:
middlewares:
- validation
- route_messages
- "Your\\Middleware\\Service"
- call_message_handler
```
A few things to note:
1. The YAML configuration creates `messenger.bus.[name]` services for the buses.
2. The YAML configuration for middleware just adds tags to the corresponding middlewares.
3. If the middleware definition does not exists, it creates it. (without any magic on the arguments though, if it isn't auto-wirable, well... "your problem")
4. In the PR, there is this "TolerateNoHandler" middleware that is a great example for event buses
Commits
-------
e5deb8499b [Messenger] Define multiple buses from the `framework.messenger.buses` configuration
This PR was squashed before being merged into the 4.1-dev branch (closes#26956).
Discussion
----------
[Messenger][AmqpExt] Allow disabling the auto-setup of the connection
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #26937
| License | MIT
| Doc PR | ø
Allow disabling the auto-setup of the AMQP connection. Especially useful when the messages are published to another system (see #26937)
Commits
-------
b3039faa1a [Messenger][AmqpExt] Allow disabling the auto-setup of the connection
This PR was squashed before being merged into the 4.1-dev branch (closes#26941).
Discussion
----------
[Messenger] Allow to configure the transport
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | ish
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #26900, #26908, #26935
| License | MIT
| Doc PR | ø
We allow users to configure the encoder/decoder used by the built-in adapter(s). This also adds the support of configuring the default's encoder/decoder format and context.
Commits
-------
1a3f0bbb14 [Messenger] Allow to configure the transport
This PR was squashed before being merged into the 4.1-dev branch (closes#26909).
Discussion
----------
[Messenger][DX] Uses the adapter name instead of the service name
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
As a developer, I don't get why I would need to use the service name while I give a name to the adapters. This is basically what this PR means for me in terms of configuration:
```patch
framework:
messenger:
routing:
# We want the command below to be handled async with the "messenger.default_sender" (AMQP producer).
- 'App\Message\Command\CreateNumber': messenger.sender.amqp
+ 'App\Message\Command\CreateNumber': amqp
adapters:
amqp: "%env(AMQP_DSN)%"
```
And in terms of pulling the messages:
```patch
- bin/console messenger:consume-messages messenger.receiver.amqp
+ bin/console messenger:consume-messages amqp
```
Commits
-------
b5afb40441 [Messenger][DX] Uses the adapter name instead of the service name
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Minor improvements and cleanup
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
- enable some of opcode optimizations
- add missing typehints
- cleanup
Commits
-------
d8cc7a4715 Minor improvements and cleanup
This PR was squashed before being merged into the 4.1-dev branch (closes#26816).
Discussion
----------
[Messenger][FrameworkBundle] Move collector, command into the component & minor tweaks
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A
Some suggestions more aligned with most of the core practices, mainly:
- Move the command & collector to the component itself. They are not dependent of the Fwb in any way and are useful out of the fwb usage.
- Add an exception in FrameworkExtension if the `framework.messenger` key is enabled, but the component isn't installed.
Commits
-------
6aec62bad3 [FrameworkBundle] Minor messenger component tweaks
f9c9ca0514 [Messenger] Move data collector & command into the component
This PR was squashed before being merged into the 4.1-dev branch (closes#26685).
Discussion
----------
[Messenger] Add a `MessageHandlerInterface` (multiple messages + auto-configuration)
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | ø
| License | MIT
| Doc PR | ø
Based on @chalasr's PR: https://github.com/symfony/symfony/pull/26672.
This reduces the hassle of registering handlers: it allows the auto-configuration with a new interface `HandlerInterface`. At the same time, it allows a handler to handle multiple messages.
Commits
-------
07e6bc73a3 [Messenger] Add a `MessageHandlerInterface` (multiple messages + auto-configuration)
This PR was merged into the 4.1-dev branch.
Discussion
----------
[Messenger] Make NoHandlerForMessageException a logic exception
| Q | A
| ------------- | ---
| Branch? | master <!-- see below -->
| Bug fix? | no
| New feature? | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks? | no <!-- see https://symfony.com/bc -->
| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tests pass? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | https://github.com/symfony/symfony/pull/26648#discussion_r178049882 <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | N/A <!-- required for new features -->
To me, a missing handler for a message is a program logic exception (or misconfiguration). Even if it's only detected at runtime here.
It's the same as `ServiceNotFoundException` which even is an `\InvalidArgumentException`. Could eventually also be the case here.
Commits
-------
0489bbd948 [Messenger] Make NoHandlerForMessageException a logic exception
