Skip to content

[Messenger] Redispatch a message in the same transport as the one defined in the configuration #60132

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.

Sign up for GitHub

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

Jump to bottom
Open
lyrixx opened this issue Apr 3, 2025 · 3 comments
Open

[Messenger] Redispatch a message in the same transport as the one defined in the configuration #60132

lyrixx opened this issue Apr 3, 2025 · 3 comments
Labels
Messenger

Comments

@lyrixx
Copy link
Member

lyrixx commented Apr 3, 2025 •
edited
Loading

Description

see last chapter of: https://symfony.com/doc/current/scheduler.html#efficient-management-with-symfony-scheduler

By default the scheduler process the message synchronously:

RecurringMessage::every('1 second', new CheckTrafficAnomalies()),

scheduler logs:

08:13:36 INFO      [messenger] Received message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies"]
CALLLLLLLLLLLLLLLLLLLLED
08:13:36 INFO      [messenger] Message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies handled by AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","handler" => "AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke"]
08:13:36 INFO      [messenger] AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies was handled successfully (acknowledging to transport). ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","message_id" => null]

We can tell it to dispatch the message to the bus, it's still synchronous

RecurringMessage::every('1 second', new RedispatchMessage(new CheckTrafficAnomalies())),

scheduler logs:

08:14:06 INFO      [messenger] Received message Symfony\Component\Messenger\Message\RedispatchMessage ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage"]
CALLLLLLLLLLLLLLLLLLLLED
08:14:06 INFO      [messenger] Message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies handled by AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","handler" => "AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke"]
08:14:06 INFO      [messenger] Message Symfony\Component\Messenger\Message\RedispatchMessage handled by Symfony\Component\Messenger\Handler\RedispatchMessageHandler::__invoke ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage","handler" => "Symfony\Component\Messenger\Handler\RedispatchMessageHandler::__invoke"]
08:14:06 INFO      [messenger] Symfony\Component\Messenger\Message\RedispatchMessage was handled successfully (acknowledging to transport). ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage","message_id" => null]

An finally we can specify a transport:

scheduler logs:

08:15:23 INFO      [messenger] Received message Symfony\Component\Messenger\Message\RedispatchMessage ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage"]
08:15:23 INFO      [messenger] Sending message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies with rabbitmq sender using Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","alias" => "rabbitmq","sender" => "Symfony\Component\Messenger\Bridge\Amqp\Transport\AmqpTransport"]
08:15:23 INFO      [messenger] Message Symfony\Component\Messenger\Message\RedispatchMessage handled by Symfony\Component\Messenger\Handler\RedispatchMessageHandler::__invoke ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage","handler" => "Symfony\Component\Messenger\Handler\RedispatchMessageHandler::__invoke"]
08:15:23 INFO      [messenger] Symfony\Component\Messenger\Message\RedispatchMessage was handled successfully (acknowledging to transport). ["class" => "Symfony\Component\Messenger\Message\RedispatchMessage","message_id" => null]

In another worker (bin/console mes:con rabbitmq)

08:15:08 INFO      [messenger] Received message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies"]
CALLLLLLLLLLLLLLLLLLLLED
08:15:08 INFO      [messenger] Message AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies handled by AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","handler" => "AppBundle\NotificationCenter\Messenger\MessageHandler\CheckTrafficAnomaliesHandler::__invoke"]
08:15:08 INFO      [messenger] AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies was handled successfully (acknowledging to transport). ["class" => "AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies","message_id" => null]

There is something I don't like here. I must duplicate the configuration between messenger.yaml (routing), and the second argument rabbitmq of new RedispatchMessage().

framework:
    messenger:
        routing:
            'AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies': rabbitmq

I noticed that few years ago, but was too lazy to raise the issue.

But now I face a real problem with that.

Depending on where I deploy the application, I want to use another transport for this message.
So I added another "config_override.yaml" (highest priority) file in my app :

framework:
    messenger:
        routing:
            'AppBundle\NotificationCenter\Messenger\Message\CheckTrafficAnomalies': in_memory

But it doesn't work since the transport is hardcoded is hardcoded.

So I propose the following

  1. If the transport name is not defined by the user (null) we use the transport configured in the configuration
  2. If it's not possible because of BC, we can use a special parameter like true to use the default

WDYT?

Example

No response
@faizanakram99
Copy link
Contributor

I personally would prefer if scheduler didn't dispatch messages synchronously and instead send them over to the configured transport (without the need of wrapping it in RedispatchMessage envelope).

@lyrixx
Copy link
Member Author

lyrixx commented May 14, 2025

I personally would prefer if scheduler didn't dispatch messages synchronously and instead send them over to the configured transport (without the need of wrapping it in RedispatchMessage envelope).

Indeed, but that would be a BC break.

@faizanakram99
Copy link
Contributor

I personally would prefer if scheduler didn't dispatch messages synchronously and instead send them over to the configured transport (without the need of wrapping it in RedispatchMessage envelope).

Indeed, but that would be a BC break.

Right, would it make sense to have a global config option something like framework.scheduler.use_scheduler_transport with default as true to avoid BC break. Setting it false will dispatch the message over configured transport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Messenger
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lyrixx @faizanakram99 @carsonbot