[Queue] Can the frameworkthrow an exception if timeout is set higher than retry_after because this can potentially lead to problems?

[amenk]

There is already a big warning on https://laravel.com/docs/10.x/queues

But would it be feasible to avoid such kind of problems full by safeguarding this and not allowing jobs with timeout > retry_after ?

If this is not the case, nasty-to-debug problems can appear as soon as having more than one worker.

[mohamedhekal]

You raise a good point about the potential for issues when the timeout is set higher than the retry delay for queued jobs in Laravel. Here are a few thoughts on how to handle this:

Adding a runtime check as you suggested to throw an exception if timeout > retry_after could be helpful to catch configuration mistakes. However, there may be some valid cases for setting a longer timeout, so it probably shouldn't be a hard error.
An alternative could be to add a warning log message if timeout > retry_after, so the developer is made aware of the potential issue but isn't blocked.
The docs could emphasize more strongly the problems that can occur when timeout and retry_after are misconfigured. Examples showing how jobs could overlap or data could be duplicated would make it very clear.
Another approach could be to have the retry logic check the current timeout and adjust the delay if needed to prevent overlap. This would prevent issues without requiring the timeout and retry values to match.

[amenk]

Thanks for your response.

However, there may be some valid cases for setting a longer timeout, so it probably shouldn't be a hard error.

That's the essence of my question: Are there valid cases for a timeout longer than retry_after? Do you have examples?
I don't want to make if over complicated and would prefer a hard error - but in case there are valid cases for this, probably I will stay happy with the big warning in the docs :-)

[amenk]

And by the way: I screenshot the wrong warning from the docs in the initial post, updated now