This would be problematic for certain types of jobs/situations (think about a job that uses a remote API which is having a transient failure; you could end up really slamming the remote with work due to the lack of some kind of back-off rescheduling).
I'm not sure yet if a simple exponential decay would be appropriate for all jobs/situations, or if we should allow the back-off algorithm to be configured (per job? per queue? per worker?).
But clearly there's room for improvement over a 10s hard-coded value!
Presently retries are hard-coded at a 10s retry.
https://github.com/apinstein/jqjobs/blob/locking-fixes/src/JQJobs/JQManagedJob.php#L450
This would be problematic for certain types of jobs/situations (think about a job that uses a remote API which is having a transient failure; you could end up really slamming the remote with work due to the lack of some kind of back-off rescheduling).
I'm not sure yet if a simple exponential decay would be appropriate for all jobs/situations, or if we should allow the back-off algorithm to be configured (per job? per queue? per worker?).
But clearly there's room for improvement over a 10s hard-coded value!