[Messenger] Prioritize receivers via transport configuration #57757
Conversation
|
Hey! I see that this is your first PR. That is great! Welcome! Symfony has a contribution guide which I suggest you to read. In short:
Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change. When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor! I am going to sit back now and wait for the reviews. Cheers! Carsonbot |
|
Hey! Thanks for your PR. You are targeting branch "7.2" but it seems your PR description refers to branch "7.2 for features". Cheers! Carsonbot |
fcecc48 to
6059d84
Compare
| @@ -263,15 +265,23 @@ private function registerReceivers(ContainerBuilder $container, array $busIds): | |||
| $receiverMapping[$id] = new Reference($id); | |||
|
|
|||
| foreach ($tags as $tag) { | |||
| $receiverPriority[$id] = max($tag['priority'] ?? 0, $receiverPriority[$id] ?? PHP_INT_MIN); | |||
There was a problem hiding this comment.
Does it happen that a receiver service has multiple messenger.receiver tags? If that never happens then the "take the max priority of all added tags" logic can be simplified to a single easier to read $receiverPriority[$id] = $tag['priority'] ?? 0.
Based on the current FrameworkExtension code it looked like the answer would be "no, that never happens" but I didn't know whether there were other edge-cases.
There was a problem hiding this comment.
why not using PriorityTaggedServiceTrait::findAndSortTaggedServices instead?
|
I think the changelogs should explain (briefly) how to define bigger to lower priorities, do |
6059d84 to
cbaae5d
Compare
cbaae5d to
a1a9526
Compare
Updated the changelog to indicate that the priority is passed on to the A higher priority (number) will go earlier than a lower priority -- https://symfony.com/doc/current/service_container/tags.html#tagged-services-with-priority |
| @@ -1612,6 +1612,7 @@ function ($a) { | |||
| ->defaultNull() | |||
| ->info('Rate limiter name to use when processing messages') | |||
| ->end() | |||
| ->integerNode('priority')->defaultValue(0)->info('Priority of this transport when the consumer is executed with the --all flag')->end() | |||
There was a problem hiding this comment.
| ->integerNode('priority')->defaultValue(0)->info('Priority of this transport when the consumer is executed with the --all flag')->end() | |
| ->integerNode('priority') | |
| ->defaultValue(0) | |
| ->info('Priority of this transport when the consumer is executed with the --all flag') | |
| ->end() |
|
this looks like a very worthwhile change. |
As follow-up on #52411 (adding the
--alloption tomessenger:consume) it would be good to be able to configure the receiver order via the transport configuration. That way, framework and bundle developers can pre-define/suggest the order in which messages should take precedence in the consumer**.Configuring the priority has only effect when the consumer is executed with the
--alloption. When it is executed by manually passing the receiver names (e.g.messenger:consume two one), the argument order is respected.**) I'm aware, with multiple bundles, this might not always fully result in the desired order of execution, but the same applies to (for example) event listeners. There are still options to overrule this.