In the default configuration, jobs that fail to run for any reason simply build up in the job table and are never cleared. The facility exists to do so via the claimTTL parameter, but this is set to zero by default. I don't believe there's any reason a job can't be re-attempted in a standard configuration, so this should probably be set to a non-zero value when the job queue object is initialized.
Version: 1.22.5
Severity: enhancement
I'm not convinced that this is fixed from what I see in JobQueueDB.php in the latest nightly. I won't claim to understand all the code, but I think jobs that have been attempted, but failed, are still never being recycled. I can confirm this behaviour as of 1.22, but don't currently have a wiki higher than that where I've been able to confirm it. It seems to be related to either the claimTTL setting (as I originally speculated) or the fact that the job_token/job_token_timestamp fields are still populated in a failed job.