-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Messenger] Add handled & sent stamps #29166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Messenger] Add handled & sent stamps #29166
Conversation
src/Symfony/Component/Messenger/Middleware/HandleMessageMiddleware.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Messenger/Middleware/SendMessageMiddleware.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Messenger/Transport/Sender/SendersLocator.php
Outdated
Show resolved
Hide resolved
src/Symfony/Component/Messenger/Transport/Sender/SendersLocatorInterface.php
Show resolved
Hide resolved
src/Symfony/Component/Messenger/Middleware/HandleMessageMiddleware.php
Outdated
Show resolved
Hide resolved
This PR was merged into the 4.2-dev branch. Discussion ---------- [Messenger] Fix typos | Q | A | ------------- | --- | Branch? | 4.2 <!-- 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 Just small typos extracted from #29166 in case it doesn't make it to 4.2. Commits ------- 7e763f9 [Messenger] Fix typos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(OK for 4.2 on my side to release asap the new semantics of keys for handlers/senders locators)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for 4.2
Even if we don't add a query bus #29167 (comment), adding tracking for handled/sent should not hurt to add to the core and allows people to add any custom logic on top of it. |
src/Symfony/Component/Messenger/Tests/Stamp/HandledStampTest.php
Outdated
Show resolved
Hide resolved
Thank you @ogizanagi. |
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](https://github.com/nicolas-grekas/symfony/blob/1c1818b87675d077808dbf7e05da84c2e1ddc9f8/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 ------- 2f5acf7 [Messenger] Add handled & sent stamps
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:
Sender are=> Updated. Yielding the sender name if provided, the FQCN otherwise.SenderInterface
instances.\get_class
is used for now, but a single message can be sent by multiple senders, including of the same class.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:
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.Makes sense to me and I think it was requested by @Nyholm before on Slack.
So, included in this PR.
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.