retrying a message that come from an exchange in a fan out mode => the message will be dispatched is all queue that are bound. It should not

That's the setup I used to test this retry mechanism and it works well. I'd love you to try and see really in which case it doesn't work :)

I think we should reconsider#23315. How I see things: I should remove everything about worker, keep only AMQP stuff, and update the Messenger to use AMQP.

If you believe you can't make the AMQP adapter much better by doing so, it is probably an interesting option (lots of work on your side though 😄).

Though, there is a point in keeping the AMQP adapter simple and not having it "fully blown featured". Obviously, there is the maintenance cost point. But also, most people will use the default auto-setuped queues, right? I also believe that everybody willing to configure the queues and exchanges very precisely will very rarely be fully satisfied by auto-configuration (regardless of the amount of effort we put into it) and end up configuring their AMQP bits manually, that's what everybody has been doing so far at the end, and this retry mechanism PR allows you to configure the routing key pattern without auto-configuring it, so this use-case would work.

Question about retries in general: If a consumed message is handled by multiple handlers but only one throws an exception - how do you handle this? It probably isn't desirable to retry the message on handlers that were successful.

Rebase needed after#27129

If a consumed message is handled by multiple handlers but only one throws an exception - how do you handle this? It probably isn't desirable to retry the message on handlers that were successful.

That's a good question. You are right, it might not be desirable to retry on successful handlers but I believe that's the only (without a crazy amount of code) way to make it simple. On the other hand, I'd argue that something "critical" (a command in the CQRS point-of-view) will only have one handler. The things that will have multiple handlers are basically event subscribers and will be projections (or similar) and there should be no problem with having them running multiple times.

PR rebased.

I suggest we go ahead with this simple (optional) retry implementation for 4.1 and replace it with the one in the AMQP component later when introduced.

@sroze another potential problem could be an exception being thrown at a point where retrying the message would cause additional problems.

What about an optional mechanism to have the subscriber tell the message bus/receiver to retry the message? This could also tell the bus to retry just this specific handler.

// in your handler/subscribertry {// ... some logic that throws an exception}catch (\Throwable$e) {thrownewRetryException(__CLASS__,$e);// or instead of __CLASS__ we can get the class from the exception's trace?}

This is probably a discussion for another place as it is a more general retry - I can open an issue if we want to discuss further.

This is probably a discussion for another place as it is a more general retry - I can open an issue if we want to discuss further.

I'd say so. Though a very good point; I'd be great if you can open an issue, describe the issue and, cherry on top, if you have an idea on how to implement, propose something :)

I don't think that fabbot's PoV is relevant here :)

Documentation PR is here:symfony/symfony-docs/pull/9756

This pull-request is welcoming another round of review 💚

@sroze how can we programatically requeue message with specified delay from handler? For example for cases, when we cann't process this message now.

can we programatically requeue message with specified delay from handler?

In the given implementation we can't. I believe that this is out of scope for now anyway and that it will be handled with the AMQP component (#27140) which will provide more features such as this one 👍

@sroze Can we talk about this one this week IRL?

@sroze do you think it would be possible to implement this in away so that it would standardize the retrying logic across the various transports?

I've brought the AMQP retry logic from Sam and put it into#30557 - but also fitting it into a system where retrying has been made generic, so it can be implemented/included in future transports.

I would LOVE review on that - I'm running full speed to get the features Messenger needs/deserves, but I need queue experts to help me avoid pitfalls.

IMHO this one could be closed in favor or#30557

Closing in favor of#30557