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

Merged
merged 1 commit into from
Aug 6, 2025

Conversation

maxbaldanza
Copy link
Contributor

@maxbaldanza maxbaldanza commented Jun 10, 2025

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

@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

@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

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
@fabpot
Copy link
Member

fabpot commented Aug 6, 2025

Thank you @maxbaldanza.

@fabpot fabpot merged commit 786b573 into symfony:7.4 Aug 6, 2025
11 checks passed
@maxbaldanza maxbaldanza deleted the sqs-retry branch August 6, 2025 09:14
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
6 participants