Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Symfony\Messenger] Default routing duplicates messages #51024

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

Closed
jokaorgua opened this issue Jul 19, 2023 · 4 comments
Closed

[Symfony\Messenger] Default routing duplicates messages #51024

jokaorgua opened this issue Jul 19, 2023 · 4 comments

Comments

@jokaorgua
Copy link

jokaorgua commented Jul 19, 2023

Symfony version(s) affected

6.2.9

Description

Due to documentation https://symfony.com/doc/current/messenger.html#routing-messages-to-a-transport we can define a default routing for all messages.

You may use '*' as the message class. This will act as a default routing rule for any message not matched under routing. This is useful to ensure no message is handled synchronously by default.

    $messenger
        ->routing('*')
        ->senders(['async']);

When we want to set a specific sender for a specific message we should use the code

$messenger->routing(MyMessage::class)->sender(['another_async']);

In my opinion this should rewrite the transport for this one specific message and send the message only to 'another_async' transport.

In reality the message is sent to async + to another_async transports. So the default '*' acts like a template for message namespaces

You may use a partial PHP namespace like 'App\Message*' to match all the messages within the matching namespace. The only requirement is that the '*' wildcard has to be placed at the end of the namespace.

How to reproduce

return static function (FrameworkConfig $framework) {
    $messenger = $framework->messenger();
    $messenger
        ->transport('async')
        ->dsn('doctrine://default')
        ->retryStrategy(['max_retries' => 3, 'multiplier' => 1, 'delay' => 1000]);

    $messenger
        ->transport('another_async')
        ->dsn('doctrine://default')
        ->retryStrategy(['max_retries' => 4, 'multiplier' => 2, 'delay' => 1000]);

    $messenger
        ->routing('*')
        ->senders(['async']);

    $messenger->routing(MyMessage::class)->sender(['another_async']);
}

Possible Solution

I see 2 possible solutions

  1. Change the documentation and specify that setting a routing for the specific message adds, not replaces, the routing.
  2. Change the behavior of routing()->senders([]) which will replace the senders for the specific message

Additional Context

No response

@valtzu
Copy link
Contributor

valtzu commented Jul 23, 2023

This is already fixed on 6.3

#48121

@derrabus
Copy link
Member

@jokaorgua Can you confirm that upgrading to 6.3 fixes the issue for you?

@jokaorgua
Copy link
Author

@jokaorgua Can you confirm that upgrading to 6.3 fixes the issue for you?

I'm not able to update my project to 6.3 currently. So I can not tell you if that helps. Sorry.

I've reviewed the PR https://github.com/symfony/symfony/pull/48121/files#diff-8e667f377e9f47d42cdc1a83364b33083f8c4bfe45ef9e934e6f102bb4c36738 and tests for the fix. I'm sure that everything works correctly but personally I do not see a test for the situation when we have something like

$messenger->routing(DummyMessage)->senders(['first']);
$messenger->routing('ParentOfDummyNamespace\*')->senders(['second']);
$messenger->routing('*')->senders(['default']);

I'm confused with code if (str_ends_with($type, '*') -> the type 'NameSpaceTemplate*' also fits this condition and I'm not really sure how it will work.

@derrabus
Copy link
Member

I'm not able to update my project to 6.3 currently.

You would only need to bump messenger to 6.3. That being said, Symfony 6.2 is going to be EOL in a couple of days, so whatever blocks you, you should sort it out soon.

So I can not tell you if that helps. Sorry.

I'm going to close the issue then and assume that it's fixed. If one fine day you've upgraded to 6.3 and the problem is still not fixed for you, please open a new issue.

@derrabus derrabus closed this as not planned Won't fix, can't repro, duplicate, stale Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants