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

Actually, I do not really understand the use case for using a negative delay. Is that really something that needs to be supported?

As far as I understand, the problem is that it does not work right now, and this can happen due to calculation, so it should "just" send the message right?

@xabbuh If you have a long queue, you can cut in front of the queue with this negative delay because messages are sorted by available_at.

So it's about priority within a single queue basically.

Actually, it was already possible to set negative delays, but the behaviour was unexpected (in my opinion). Another solution could be to set the time to "now" in case of a negative delay. But then use cases like described by @valtzu wouldn't be supported.

I'm not certain on this because:

• we should never expect things based on bridge implementation details
• i'm not certain it really "works" with this PR (everytime for everyone i mean).. I think about postgres notify behaviour, hard indexes on dbs... So this would need a loot of tests .. it this worth the effort ?

As i see it, you removed a valid safeguard in the code to allow a "non-written" behaviour.. and i'm pretty sure this will not lead to good things :)

And finally... there is a simpler / documented way to handle queue priority: queue priority. On a fonctional level, does this not fill your needs ?

I agree that you can discuss about the expected behaviour, but I think that what you at least wouldn't expect, is that a negative delay is converted to a positive delay. How it's supposed to work apart from that, could maybe remain undefined.

I agree that you can discuss about the expected behaviour, but I think that what you at least wouldn't expect, is that a negative delay is converted to a positive delay. How it's supposed to work apart from that, could maybe remain undefined.

I totally agree!

@J-roen Can you create a PR for Symfony 5.4, which is also affected?

@J-roen Can you create a PR for Symfony 5.4, which is also affected?

Yes, I can do that later this week. And what about 7.x?