Job is retried even when tries is set to 1 for queue:work

[jasonmccreary]

• Laravel Version: 5.3.8
• PHP Version: 7.0.10
• Database Driver & Version: MySQL 5.7

Description:

My job is getting retried even though the --tries option for queue:work is set to 1. While the job is longer running than the retry_after value, I would expect the Job to fail rather than be retried given that tries is 1.

It's worth noting that my queue did not behave this way in Laravel 5.2. For now, I have set my retry_after to 3600. But this seems hackish. At the least, I'd prefer to set this to something like 0 to indicate do not retry.

Steps To Reproduce:

Queue a job that runs longer than your retry_after value.

[GrahamCampbell]

This is the expected behaviour. If a job times out, it is run for the first time again, or whatever time it was at.

[GrahamCampbell]

Make sure you set the timeout correctly to prevent this.

[jasonmccreary]

Fair enough. But this does seemed to have changed from 5.2. Not sure if that was a retry_after vs expire/ttlor if the default timeout changed.

Regardless, what is the correct timeout so I don't need to set retry_after to an arbitrarily high number to avoid the job retrying?

[dbpolito]

I'm seeing this problem too... And i agree with @jasonmccreary that this looks odd.

If we have a job timeout to 300, and retry_after to 90, laravel basically notifies that this job failed, but the worker is still running the job and it does succeeds.

I think the way we handle timeouts can be better handled maybe here: https://github.com/laravel/framework/blob/5.5/src/Illuminate/Queue/Worker.php#L140

Like doing the logic to check job, fail, instead of simply exiting here and doing all the logic on the next try.

[stevevg]

I agree with @dbpolito.
For a project I am developing, there is a background job that may be running for some minutes, but I cannot cap or know the exact amount of time it will take it a-priori.
It is very odd that after 60 seconds I get a notification of a failed job, while the job is actually still running and it successfully completes after n minutes.

As a possibile solution, I am thinking about a default retry_after, set in config/queue, which may be overridden in the job class definition, as it happens with timeout.

[nicktc]

Same here, very strange behavior. Isn't there an option to disable retry_after at all?

[lawrencekm]

I did
queue work tries=0
and the retires stopped

[fernando2amigos]

Laravel 8.x and this seems to behave still like this.
Getting a timeout after retry_after=90/tries=1 while job is still running to finally succeed.

Like other params, retry_after should be able to override in job instead of setting a ridiculous high value.