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

I've already done it in a nodeJS project and it works well in production.

async function createDelayedQueue(channel, exchange, queue, delay) {
    const date = new Date().toISOString().split('T')[0];
    const delayedQueue = `delay_${exchange}_${queue}_${delay}_${date}`;
    const delayedExchange = 'delays';
    const baseExpire = 24 * 60 * 60 * 1000;

    await channel.assertQueue(delayedQueue, {
        durable: true,
        arguments: {
            'x-message-ttl': delay,
            'x-expires': delay + 60 * 1000 + baseExpire,
            'x-dead-letter-exchange': exchange,
            'x-dead-letter-routing-key': queue,
            'x-queue-type': 'quorum'
        }
    });

    await channel.bindQueue(delayedQueue, delayedExchange, delayedQueue);
    
    return { delayedQueue, delayedExchange }; 
}

This probably also affect 6.4, right?

This probably also affect 6.4, right?

Yes, that's right

Sorry, I've tried to change the base branch to 6.4 and by mistake it has added automatically the reviewers, feel free to leave 🙏
I come back to point to 7.2, as it add a lot of change to the PR, my fault.

No worries, we can target 6.4 while merging this PR 👍

Hi there! Just a friendly ping to see if there's anything else needed on this PR or if it can be reviewed when you get a chance. Thanks a lot for your time!

Hi everyone!
My devops team requested us to use Quorum queues and I can confirm we are also affected by this. Please let my know if I can help.

As this is a new feature, it must target 7.4 branch

As this is a new feature, it must target 7.4 branch

Well, I consider it as a bug fix, because is causing problems when you use symfony with quorum rabbitmq queues, but, for me it's not a problem target it to 7.4

Hi,

My concern was whether the second message (published at 11:00 PM) would be processed too early because it enters a delay queue that already exists due to the earlier message.

Actually, these are two separate concepts: the queue's duration and the message's TTL. The second message will be dead-lettered to the final queue only after its own TTL expires, regardless of when the queue was created or when the first message entered it.

The mechanism is exactly the same as the one already used today. The difference is that with classic queues, if you redeclare the queue, its expiration is refreshed. With quorum queues, this doesn't happen—so we must ensure that the queue lasts long enough for all its messages. That’s why I create a delay queue per day with a TTL of delay + 1 day: this way, we ensure messages are processed properly, and we can still clean up old queues.

It is not possible to create a retry/delay queue of type quorum in Symfony 6.4 (tested).

This is not entirely accurate. You can set the default queue type for a RabbitMQ Virtual Host. That’s actually how I discovered this issue: in our setup, quorum is the default queue type (after the bug we had to put classic as a default).

I’m not arguing whether this is a bug or a missing feature, and I’m OK with this being addressed in Symfony 7.4. My goal is simply to move the PR forward, because RabbitMQ is deprecating classic mirrored queues. In RabbitMQ 4, quorum we won't be able to create a HA classic queues.

Alternative approach

This was actually the first solution I tried when we started migrating from Beanstalkd (which has native support for delayed messages, and is very simple to use). Unfortunately, this approach has a critical issue: delay queues process messages in order. If the first message has a delay of 5 minutes, and the second one only 5 seconds, the second one will wait for the first to expire before being processed.

This is why Symfony Messenger creates one queue per delay duration. It avoids the head-of-line blocking problem that comes with FIFO processing in delay queues.

As I said previously, we even have some services in Node.js that use the same pattern. They’ve been running smoothly for over 6 months, with quorum queues, no message loss, and proper queue cleanup.

I know this is a complex topic to fully explain in a PR comment, and English is not my first language—so if anything is unclear, please let me know and I’ll try to explain it differently.

Thanks again for your feedback and time.

@miquel-angel thanks for your time answering my comments. I learn a lot. Big thanks for your contribution. I'm looking forward to your PR to be merged :D

@OskarStark I edited my comment to remove inexact information. Thanks for the feedback.

Hi,
There are 2 checks that are failing, Psalm and Unit Tests, but I think that they are failing too in symfony/7.2.
I've already done a rebase from upstream 7.2.
What should I have to do now?

Thanks!