Commit 9a84061
committed
feature #29166 [Messenger] Add handled & sent stamps (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
-------
2f5acf790a [Messenger] Add handled & sent stampsFile tree
2 files changed
+8
-4
lines changed- DependencyInjection
- Tests/DependencyInjection
2 files changed
+8
-4
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1578 | 1578 | | |
1579 | 1579 | | |
1580 | 1580 | | |
1581 | | - | |
1582 | | - | |
1583 | | - | |
| 1581 | + | |
| 1582 | + | |
| 1583 | + | |
| 1584 | + | |
1584 | 1585 | | |
1585 | 1586 | | |
1586 | 1587 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
569 | 569 | | |
570 | 570 | | |
571 | 571 | | |
572 | | - | |
| 572 | + | |
| 573 | + | |
| 574 | + | |
| 575 | + | |
573 | 576 | | |
574 | 577 | | |
575 | 578 | | |
| |||
0 commit comments