This PR was merged into the 4.3-dev branch.
Discussion
----------
[Messenger] Adding the "sync" transport to call handlers synchronously
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | symfony/symfony-docs#11236
This adds a `sync://` transport that just calls the handlers immediately. Why? This allows you to route your messages to some "async" transport. But then, when developing locally or running your tests, you can choose to run them synchronously instead:
```yml
# config/packages/messenger.yaml
framework:
messenger:
transports:
async: '%env(MESSENGER_TRANSPORT_DSN)%'
routing:
'App\Message\SmsNotification': async
'App\Message\OtherMessage': async
```
```
# .env
# by default, handle this sync
MESSENGER_TRANSPORT_DSN=sync://
```
```
# .env.local on production (or set this via real env vars)
# on production, use amqp
MESSENGER_TRANSPORT_DSN=amqp://.......
```
Cheers!
Commits
-------
3da5a438aa Adding the "sync" transport to call handlers synchronously
This PR was merged into the 4.3-dev branch.
Discussion
----------
Add optional parameter `prefetching` for AMQP connection
Add prefetching connection parameter to setup channel prefetch count.
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
When setting up AMQP transport connection, it can be interesting to configure prefetching on a channel, which is not currently possible.
Commits
-------
47777eedd6 Add optional parameter `prefetching` in connection configuration, to setup channel prefetch count
This PR was merged into the 4.3-dev branch.
Discussion
----------
[Messenger] Add a command to setup transports
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| License | MIT
This PR add a `SetupTransportsCommand` that allow to setup the transports.
Actually the `AMQPTransport` is setup only if debug is enabled. With this PR the new `messenger:setup-transports` will setup all declared transports.
Commits
-------
fbb534a838 [Messenger] Add a command to setup transports
This PR was merged into the 4.3-dev branch.
Discussion
----------
[Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | -
| License | MIT
| Doc PR | -
This PR adds a new `EventDispatcherInterface` in `Contracts`. This interface contains only one method: `dispatch($event, $eventName)`. That covers almost all use cases of the event dispatcher in components (some use add/removeListeners/Subscribers but they are a minority.)
While doing so, it allows dispatching any objects as events - not only instances of `Event`.
This allows decoupling e.g. `Messenger` from the `EventDispatcher` component.
Next steps could be about planning to remove the base `Event` class from some concrete event classes and/or moving `EventSubscriberInterface` to `symfony/contracts`. It would allow decoupling e.g. `Workflow` from the component - but that's too far away for now, let's think about it in 5.1.
Commits
-------
3c3db2f14a [Contracts][EventDispatcher] add EventDispatcherInterface to symfony/contracts and use it where possible
This purpose of this event is to be a hook when a message is sent to a transport.
If that message is redelivered later, that's not the purpose of this hook (there
are Worker events for that) and could cause problems if the user unknowingly
tries to modify the Envelope in some way, not thinking about how this might
be a redelivery message.
This PR was merged into the 4.3-dev branch.
Discussion
----------
Fixing a bug where messenger:consume could send message to wrong bus
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | arguably, yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | #30631
| License | MIT
| Doc PR | Not needed
This fixes#30631, where you can run `messener:consume` and accidentally sent received messages into the wrong bus.
The fix (done via middleware) is to attach a "bus name" to the `Envelope` and use it when the message is received to find that bus.
Commits
-------
ef077cf26c Fixing a bug where a transport could receive a message and dispatch it to a different bus
This PR was merged into the 4.3-dev branch.
Discussion
----------
Dispatching two events when a message is sent & handled
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | yes
| BC breaks? | no
| Deprecations? | no
| Tests pass? | yes
| Fixed tickets | none
| License | MIT
| Doc PR | TODO
Alternative to #30646. This uses a more generic system, so you could do anything when a message is sent. The main use-case is when a message is dispatched by a 3rd party.
I didn't try to add *exhaustive* events everywhere: I added an event for a very specific use-case:
When a message is dispatched by a 3rd party, being able to add stamps (e.g. `DelayStamp` or a future `AmqpRoutingKeyStamp` before the message is sent. Example:
```php
class MailerMessageSendToTransportEventSubscriber implements EventSubscriberInterface
{
public function onSendMessage(SendMessageToTransportsEvent $event)
{
$envelope = $event->getEnvelope();
if (!$envelope->getMessage() instanceof SomeMailerMessage) {
return;
}
$event->setEnvelope($envelope->with(new AmpqRoutingKeyStamp('mailer-route')));
}
public static function getSubscribedEvents()
{
return [SendMessageToTransportsEvent::class => 'onSendMessage'];
}
}
```
Along with #30557, we will now have the following events, regarding async messages:
* Event when a message is sent to transports (this PR)
* Event when a message is received from transport, but before handling it
* Event when a message is received from transport and after handling it
Commits
-------
a7ad1b4ccc Dispatching two events when a message is sent & handled
* 4.2: (27 commits)
cs fix
cs fix
[PHPUnit-Bridge] override some environment variables
[TwigBridge] Remove use spaceless tag
Upgrade zookeeper ext
[translation] Update defaut format from yml to yaml
Change default log level for output streams
update docblock to match the actual behavior
Don't resolve the Deprecation error handler mode until a deprecation is triggered
compatibility with phpunit8
Make 'headers' key optional for encoded messages
[Debug][DebugClassLoader] Detect annotations before blank docblock lines on final and internal methods
Fix undefined variable fromConstructor when passing context to getTypes
Added translations for chineese language.
Allow 3rd argument to be null
Remove whitespace (tab on blank line)
[Monolog] Really reset logger when calling logger::reset()
[Form] Fixes debug:form appears many times as type extensions configured with new getExtendedTypes method
Update src/Symfony/Component/PropertyInfo/Tests/Extractor/ReflectionExtractorTest.php
Update src/Symfony/Component/PropertyInfo/Tests/Extractor/ReflectionExtractorTest.php
...
* 4.2:
Add missing `@internal` annotations
Disable Twig in the profiler menu when Twig is not used
Mark some/most implementations of Serializable as `@internal`
[Config] ensure moving away from Serializable wont break cache:clear
[VarDumper] dont implement Serializable in Stub
[Config] fix compat with wrapping autoloaders
[Messenger] fixed RabbitMQ arguments not passed as integer values
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] Improved message when handler class does not exist
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | no
| New feature? | no
| BC breaks? | no
| Deprecations? |no
| Tests pass? | yes
| Fixed tickets |
| License | MIT
| Doc PR |
**Problem:**
When defining a non existing messenger handler class in the `services.yml` config file, we encounter this confusing error message:
```
services:
App\Handler\NonExistentHandler:
tags: [messenger.message_handler]
```
```
PHP Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Argument 1 passed to Symfony\Component\Messenger\DependencyInjection\MessengerPass::guessHandledClasses() must be an instance of ReflectionClass, null given, called in /app/vendor/symfony/messenger/DependencyInjection/MessengerPass.php on line 93 in /app/vendor/symfony/messenger/DependencyInjection/MessengerPass.php:189
Stack trace:
#0 /app/vendor/symfony/messenger/DependencyInjection/MessengerPass.php(93): Symfony\Component\Messenger\DependencyInjection\MessengerPass->guessHandledClasses(NULL, 'App\\Application...')
#1 /app/vendor/symfony/messenger/DependencyInjection/MessengerPass.php(74): Symfony\Component\Messenger\DependencyInjection\MessengerPass->registerHandlers(Object(Symfony\Component\DependencyInjection\ContainerBuilder), Array)
#2 /app/vendor/symfony/dependency-injection/Compiler/Compiler.php(95): Symfony\Component\Messenger\DependencyInjection\MessengerPass->process(Object(Symfony\Component\DependencyInjection\ContainerBuilder))
#3 / in /app/vendor/symfony/messenger/DependencyInjection/MessengerPass.php on line 189
```
**Proposal:**
We can throw a more relevant exception (RuntimeException) in this case to help the developer to have a better understanding of the issue.
```Invalid service "App\Handler\NonExistentHandler": class "App\Handler\NonExistentHandler" does not exist.```
Commits
-------
6ab9274638 Improve error message when defining messenger handler class that does not exists
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] Add handled & sent stamps
| Q | A
| ------------- | ---
| Branch? | 4.2 <!-- 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? | yes <!-- please add some, will be required by reviewers -->
| Fixed tickets | N/A <!-- #-prefixed issue number(s), if any -->
| License | MIT
| Doc PR | symfony/symfony-docs/issues/10661
Based on #29159
This new feature marks sent and handled messages, so middleware can act upon these and use the handler(s) result(s).
This is also the base of a next PR (#29167), introducing a query bus built on top of the message bus.
I'm not sure yet about the best way to determine the handlers and senders names/descriptions to store in the stamps:
- Handlers are callable. I've just reused the [console text descriptor](1c1818b876/src/Symfony/Bundle/FrameworkBundle/Console/Descriptor/TextDescriptor.php (L457-L491)) format for now.
- ~~Sender are `SenderInterface` instances. `\get_class` is used for now, but a single message can be sent by multiple senders, including of the same class.~~ => Updated. Yielding the sender name if provided, the FQCN otherwise.
~~Instead, what about allowing to yield names from locators, and fallback on the above strategies otherwise? So we'll use transport names from the config for senders, and pre-computed compile-time handlers descriptions?~~
=> Done. For handlers, computing it at compile time might not be straightforward. Let's compute it lazily from `HandledStamp::fromCallable()`
---
### From previous conversations:
> What about not adding HandledStamp on `null` returned from handler
IMHO, `null` still is a result. The stamps allows to identify a message as being handled regardless of the returned value, so makes sense on its own and keeping would require one less check for those wanting to consume it.
> What about adding SentStamp?
Makes sense to me and I think it was requested by @Nyholm before on Slack.
So, included in this PR.
> Should it target 4.2 or 4.3?
Targeting 4.2, because of the removal of the handler result forwarding by middleware. A userland middleware could have used this result, typically a cache middleware. Which would now require extra boring code in userland. This will simplify it and allow users to create their query bus instance until 4.3.
Commits
-------
2f5acf790a [Messenger] Add handled & sent stamps
This PR was merged into the 4.2-dev branch.
Discussion
----------
[Messenger] Fix collecting messages
| Q | A
| ------------- | ---
| Branch? | master
| Bug fix? | yes
| New feature? | no
| BC breaks? | no-ish
| 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 -->
In 4.2 there's always one dispatched message because we provide the template with a generator. Calling `{{ gen|length }}` always returns `1`
Before
After
Commits
-------
bfc7d94169 [Messenger] Fix collecting messages
