In my implementation I could not avoid minor incompatible change: queue_name_pattern has changed, so looks like this cannot be released under 4.4 or 5.0. Can we include it into 5.1 please?

Neither would this be allowed in master since it would break apps migrating to 5.2. Can we find another idea?

Neither would this be allowed in master since it would break apps migrating to 5.2. Can we find another idea?

@nicolas-grekas Thank you for the feedback. I changed it: nowqueue_name_pattern remains backward compatible, but I changed internals of queue name construction.

Should I change target branch in this case?

Yes please if this should be considered as a bugfix (I didn't check that part).

@nicolas-grekas changed target to 4.4

#36196 and#36212 already try to solve the same problem.

@theravel i was able to solve this and few other problems without changing Messenger connection class, but it's little bit tricky. Here is an examplehttps://github.com/s-code/amqp-extra-bundle. Take a look on ExtraAmqpFactory, ExtraAmqpSender, ExtraAmqpQueue, ExtraAmqpExchange.
As for me, splitting of retry and delay logic is a must have for amqp transport.

On a high level, this makes sense to me:

If a message is in queue A, and I read it from queue A and it fails, then it should go back onto queue A only.

Messenger handles retries by actually ack'ing the original message and redelivering it. But ultimately, the desired behavior (I think) would be what I described above and what this PR does.

Though, apparently this and#38486 solve the same problem (is it theexact same problem?) but in different ways.@s-code could you comment on what your PR does versus this one?

Thanks :)

@weaverryan you are right. This two pull requests solve the same problem. The difference is in next things:

1. Delay queue naming convention.

• [Messenger] Ability to distinguish retry and delay actions #36864 requires its change fromdelay_{exchange}_{routing_key}_{time} todelay_{exchange}_{routing_key}_{time}_(retry|delay). So as result we havedelay_messages_message1_500_retry,delay_messages_message1_500_delay queues names for default configuration

• In[Messenger] Add possibility to route delayed messages to the origin queue directly #38486 there is no changes in this convention. In case of retry{exchange} = default exchange = '', {routing_key} = origin queue name, because for default exchangequeue name is using asrouting key. So queues names look likedelay__queue1_500 anddelay_messages_message1_500

2. [Messenger] Add possibility to route delayed messages to the origin queue directly #38486 allows to use default exchange for delay and retry logic. If in configuration we define delay.exchange_name as '', no extra ("delays") exchange will be created. For me it's more elegant and clean solution

(please add a changelog entry in the bridge)

@nicolas-grekas Changelog entry added

Thank you@theravel and@MichaelKubovic for confirming.

Thank your for this feature. Please update the docs too =)