Framework: 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?