[Messenger] Allow SQS to handle its own retry/DLQ #60754
Conversation
|
Hey! Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.4 for features". Cheers! Carsonbot |
| @@ -101,6 +102,7 @@ public function __destruct() | |||
| * * wait_time: long polling duration in seconds (Default: 20) | |||
| * * poll_timeout: amount of seconds the transport should wait for new message | |||
| * * visibility_timeout: amount of seconds the message won't be visible | |||
| * * delete_on_rejection: Whether to delete message on rejection or allow SQS to handle retries. (Default: true). If set to false then the `retry_strategy` should be set to `max_retries: 0` | |||
There was a problem hiding this comment.
Ideally we should throw an error if setting delete_on_rejection and the retry_strategy doesn't have max_retries set as 0 as this option should only be used if SQS is fully responsible for the retries/DLQ but we don't have access to that so was hoping documentation is enough to cover that.
Would love to hear thoughts here
There was a problem hiding this comment.
why should it be set to 0? what happens if that's not set as documented?
There was a problem hiding this comment.
You'd end up with a duplicate message in SQS.
When the message is rejected we'd change the visibility of the message meaning it will reappear in the queue after the timeout period but then the SendFailedMessageForRetryListener would then also resend the message back to SQS meaning you'd end up with 2 of the same messages in SQS.
If the transports had access to the retry strategy then an exception could be thrown if this configuration was setup but I didn't want to introduce adding the retry strategy to transports before first making sure that was the route to take. You may also have a better way to solve that
There was a problem hiding this comment.
setting max_retries to 0 won't disable resending another message to the queue as RecoverableExceptionInterface and some other cases are always retried even if max_retries is 0 or reached its max.
There was a problem hiding this comment.
Yes your right @deguif, thanks for pointing that out 🙌
I've just pushed a change that should solve that, instead now the transport checks if the message is being resent using the RedeliveryStamp and if so we don't send it to the sender.
Let me know what you think
Thanks Carsonbot I fixed the mistake |
Allow SQS to handle retries rather then handling this by Symfony. This allows applications to use the retry strategy from SQS rather then Symfony. The default is for the message to be deleted from SQS at which point Symfony will handle the retry by deleting and then adding back in to the queue. If `delete_on_rejection` is set to `false` instead it will change the message visibility of the message on SQS and thus SQS to handle the retry mechanism
Allow SQS to handle retries rather then handling this by Symfony.
This allows applications to use the retry strategy from SQS rather then Symfony.
The default is for the message to be deleted from SQS at which point Symfony
will handle the retry by then adding back in to the queue.
If
delete_on_rejectionis set tofalseinstead it will change the messagevisibility of the message on SQS and thus SQS to handle the retry mechanism
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
As mentioned on the linked issue this has a number of benefits but mainly