Hey!

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

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.4 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

Branch rebased, commits squashed.

Rebased. Still waiting for review

Hi @Greg0 !

Is there a chance for you to target 6.4?

Thanks and have a good day!

@GrzegorzDrozd AFAIR features can be proposed only for future releases. That one will target probably nearest v8.1

7.4 and 8.0 are in RC stage

@GrzegorzDrozd AFAIR features can be proposed only for future releases. That one will target probably nearest v8.1

7.4 and 8.0 are in RC stage

What if we threat this as a bug. In fact code prevents you from sending message using a fair queue mechanism.

@GrzegorzDrozd AFAIR features can be proposed only for future releases. That one will target probably nearest v8.1

7.4 and 8.0 are in RC stage

What if we threat this as a bug. In fact code prevents you from sending message using a fair queue mechanism.

I would say code just not supports it instead of supporting it in wrong way (bug). AWS introduced that in Q2 2025 so it's new feature in SQS itself.

Docs about contributing describes clearly what is what.
I want and need that change in my daily work too 😊

There is always possibility of forking messenger SQS lib and applying such changes in private scope.

Symfony docs update
symfony/symfony-docs#21598

I'm wondering whether we should throw an exception when both the Fifo and Fair stamps are set instead of silently ignoring the Fair stamp.

And the readme of the bridge should document that bridge-specific stamp (symfony-docs currently does not have dedicated documentation pages for each platform bridge)

Would you like me to place change that will throw exception in that specific case? I do not have strong arguments to follow any of proposed paths (silent ignore or exception throwing). Exception make sense because it's not expected to use that both stamps and the same time.

@stof Actually, after thinking about this more carefully, I believe keeping the silent precedence is the better approach.
Here's why:
The AmazonSqsFifoStamp is often added automatically by the transport layer when it detects a .fifo queue suffix (which is forced by AWS). In multi-tenant applications, it's common to have middleware that could automatically add AmazonSqsFairQueueStamp globally to all messages for tenant isolation.

This creates a practical conflict: if we throw an exception when both stamps are present, it would force developers to add complex conditional logic in their middleware to check queue types before adding the fair queue stamp. This is particularly problematic because:

• Middleware typically doesn't have visibility into the transport configuration or queue naming
• It would break the composability of stamps and middleware

The current behavior (FIFO taking precedence) is actually the correct AWS behavior - FIFO queues already guarantee ordering and uses the same MessageGroupId attribute internally, so the fair queue stamp would be redundant anyway.

If we want to be more explicit, we could:

• Add a debug log when both stamps are present and FIFO takes precedence
• Document this behavior clearly in the stamp's docblock

But throwing an exception would make the feature harder to use in real-world scenarios where automatic stamp application is needed.

What do you think?

And the readme of the bridge should document that bridge-specific stamp (symfony-docs currently does not have dedicated documentation pages for each platform bridge)

@stof I've updated bridge readme