Add option to exclude locked jobs (i.e. currently being processed) in jobs:check.

[joshuapinter]

If a job is currently being processed, we want an option to exclude them from being reported in jobs:check.

jobs:check’s primary purpose should be to see the outstanding queue, not determining long-running jobs.

Made this option default to false so no breaking changes but simply pass true for not_locked to exclude them from this check.

Fixes #1127

[joshuapinter]

Ping! Any interest in getting this merged? If so, what do I need to do to move it forward? Write some tests, changelog, etc.?

Let me know and I'll get on it. I would like to get back to the main fork.

Thanks!

[albus522]

I posted a reply last night, but apparently it failed to actually submit, that's annoying.

Excluding running jobs is probably the right approach, but locked_at NULL isn't quite right. If a job is locked in a loop killing off workers, this task should probably also kick out an error. Using ready_ro_run probably carries the intention a bit better. https://github.com/collectiveidea/delayed_job_active_record/blob/master/lib/delayed/backend/active_record.rb#L55 This wouldn't be perfect as a worker could pick up the job after the lock expires and crash potentially keeping the issue quiet, but it is slightly better than only checking locked_at is set. The worker name argument can be any string that doesn't collide with a real worker name, "running job:check" would probably do.

And while not this PR's problem, it turns out when jobs:check was added, it was kind of half baked. For one, this is a very ActiveRecord specific implementation which should have been contained in https://github.com/collectiveidea/delayed_job_active_record. The task is ok here, but most of the implementation should have been over there. While I am not sure any of the other backends are actually maintained, it would have been better to continue the pattern. And created_at was the wrong marker for sitting around too long. DJ allows scheduling future jobs and this check would trip over those. run_at would be better.