NotificationsYou must be signed in to change notification settings
Fork9.6k
Star30.4k

[Messenger] [Amqp] Allow sendable AmqpStamp for failure routing#59161

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Open

nitneuk wants to merge1 commit intosymfony:7.4

base:7.4

Choose a base branch

fromnitneuk:fix-amqp-failure-routing

Open

[Messenger] [Amqp] Allow sendable AmqpStamp for failure routing#59161

nitneuk wants to merge1 commit intosymfony:7.4fromnitneuk:fix-amqp-failure-routing

+53 −3

Conversation

Copy link

nitneuk commentedDec 10, 2024

Q	A
Branch?	7.3
Bug fix?	no
New feature?	no
Deprecations?	no
Issues
License	MIT

This PR allows to route message through failure transport using AMQP routing key.

Problem statement:
For business purpose, we wanted to route failed message to different queues. This were impossible due to several things :

AmqpStamp implementsNonSendableStampInterface so, it's removed on serialization, and we couldn't retrieve it afterSendFailedMessageToFailureTransportListener sends the envelope to failure transport.
if a retry occurred, then theAmqpSender set the routing to the queue name instead of the initial routing key

Example
Here's an example of a messenger configuration that could use it:

framework:    messenger:        failure_transport: failure    transports:        failure:                dsn: '%env(resolve:AMQP_DSN)%/failure_exchange'                options:                    queues:                        failure_queue_1:                            binding_keys: ['routing_key_1']                        failure_queue_2:                            binding_keys: ['routing_key_2']        transport_1:                dsn: '%env(resolve:AMQP_DSN)%/exchange'                options:                    queues:                        queue_1:                            binding_keys: ['routing_key_1']        transport_2:                dsn: '%env(resolve:AMQP_DSN)%/exchange'                options:                    queues:                        queue_2:                            binding_keys: ['routing_key_2']

This config would create :

exchange     \____routing_key_1____ queue_1     \____routing_key_2____ queue_2failure_exchange     \____routing_key_1____ failure_queue_1     \____routing_key_2____ failure_queue_2

[Messenger] [Amqp] Allow sendable AmqpStamp for failure routing

532ed61

carsonbot added Status: Needs Review Messenger labels

Dec 10, 2024

carsonbot added this to the7.3 milestone

Dec 10, 2024

Copy link

carsonbot commentedDec 10, 2024

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has acontribution guide which I suggest you to read.

In short:

Always add tests
Keep backward compatibility (seehttps://symfony.com/bc).
Bug fixes must be submitted against the lowest maintained branch where they apply (seehttps://symfony.com/releases)
Features and deprecations must be submitted against the 7.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

chalasr self-requested a review

December 11, 2024 12:10

Copy link

Member

chalasr commentedDec 19, 2024

I couldn't find a good reason for this stamp to be non-sendable except that no use case needed it yet. This one looks legit so 👍 for me. Can you add some words about this change to the bridge's CHANGELOG?

Copy link

Member

stof commentedDec 19, 2024

Some of the stamp attributes don't make sense to be serialized and sent alongside another message (like the message id for instance). So maybe only a subset of it should be sendable. But I don't know enough about the internals of Messenger to be sure about it.