[Messenger] SF 4.3 AMQP publish with delay invalid x-dead-letter-routing-key #31241
Labels
Comments
fabpot
added a commit
that referenced
this issue
May 7, 2019
…weaverryan) This PR was merged into the 4.3-dev branch. Discussion ---------- [Messenger] Adding final routing key to delay queue name | Q | A | ------------- | --- | Branch? | master | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #31241 | License | MIT | Doc PR | n/a Fixes #31241. When we delay, we create a queue whose `x-message-ttl` matches the delay length and `x-dead-letter-routing-key` matches the original routing key used for the message. However, before this PR, the original routing key was not part of that queue's name. The result is that if two messages were delayed by the same length, but with different routing keys, the second would try to "redeclare" the existing delay queue with a new `x-dead-letter-routing-key`, resulting in an error similar to: > Server channel error: 406, message: PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-routing-key' for queue 'delay_queue_1000' Integration test was improved to catch this. Cheers! Commits ------- 9940e71 fixing a bug where the delay queue name did not contain the final routing key
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected: 4.3
Description
When publish a message to a queue A with a routing key A
, if the message handling fails, the message will be retried 3 times by default and also a DelayStamp will be added to the envelope. So because the DelayStamp was added, the message will be published using the publishWithDelay of the AmqpExt\Connection class. That function will also call the setupDelay function, which will setup a delay queue, by default namedelay_queue_1000. This delay queue will have the argumentx-dead-letter-routing-keyto the routing key of the message (Ain this case), so after the message is released from this queue it can be re-published with the correct routing key.However, a problem happens if a message is published to lets say a queue B with routing key B
. If the handling of this message also fails, the DelayStamp will also be added to the envelope, so a the delay queue will again be setup. However, since by default the same queue namedelay_queue_1000will be used, and that queue already had the argumentx-dead-letter-routing-keyset to the routing key A, then the same argument can not be set to the routing key B`.How to reproduce
Have two messages published with different routing keys (may also need to be published to different transports). When running the consume command for the first message, the handling should fail so the message should be retried 3 times. Run the consume command for the second message, which handling should also fail. Notice that an error with the message
Server channel error: 406, message: PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-routing-key' for queue 'delay_queue_1000'will appear in the console.Possible Solution
Have multiple delay queues depending on routing key.
OR
Do not associate the delay queue with a routing key and use stamps to handle the routing key (not sure if this is possible)
The text was updated successfully, but these errors were encountered: