Skip to content

[Messenger] Allow SQS to handle its own retry/DLQ #60754

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.

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

Open
wants to merge 1 commit into
base: 7.4
Choose a base branch
from

Conversation

maxbaldanza
Copy link
Contributor

@maxbaldanza maxbaldanza commented Jun 10, 2025

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_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

https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

Q A
Branch? 7.4
Bug fix? no
New feature? yes
Deprecations? no
Issues Fix #45104
License MIT

As mentioned on the linked issue this has a number of benefits but mainly

  • The consumer no longer needs to be able to send messages into the queue.
  • Less chance of message loss

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
@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.4 for features".
Could you update the PR description or change target branch? This helps core maintainers a lot.

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`
Copy link
Contributor Author

@maxbaldanza maxbaldanza Jun 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@maxbaldanza maxbaldanza changed the title [Messenger] Allow SQS to handle it's own retry/DLQ [Messenger] Allow SQS to handle its own retry/DLQ Jun 11, 2025
@maxbaldanza
Copy link
Contributor Author

Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.4 for features". Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

Thanks Carsonbot I fixed the mistake

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Symfony SQS Transport not compatible with SQS-DLQs
2 participants