Question regarding retries on interrupt

[Rammanor]

Hi,
we have this config:

include GoodJob::ActiveJobExtensions::InterruptErrors
retry_on GoodJob::InterruptError, wait: 2.minutes, attempts: 2

From the documentation:
"If you need more control over interrupt-caused retries, include the GoodJob::ActiveJobExtensions::InterruptErrors extension in your job class. When an interrupted job is retried, the extension will raise a GoodJob::InterruptError exception within the job, which allows you to use Active Job's retry_on and discard_on to control the behavior of the job."

Does that mean that the second time the job is picked the worker only raises the interrupt error but won't run the job?
1st attempt -> worker dies
2nd attempt -> worker raises error

Does GoodJob need a minimum of 3 attempts to re-run the job in this case?

Thanks

[johncalvinyoung]

Near as I can tell in digging into this behavior, the attempts will limit actual runs of the job, and will not count the worker-raised exceptions.

In my case (debugging a job that sometimes provokes an OOM error), I have a retry_on GoodJob::InterruptError, attempts: 2 but once the job runs out of retries, it'll show four executions (of which two actually attempted to run the job, and two simply raised exceptions).

[bensheldon]

If the job is interrupted the attempts value is never updated to record the attempt.

It's confusing because attempts is an Active Job thing, whereas executions are a GoodJob thing. GoodJob keeps finer-grained accounting than Active Job.

An execution record is created every time a job starts performing. If that is interrupted, it is implicitly/passively unlocked, and then when the job is re-performed GoodJob notices that there is an existing execution record in an unfinished state, cleans up the old execution, and raises an InterruptError through Active Job for the current execution.

The confusing thing is there are two executions both with InterruptError:

1. the execution that was system interrupted that get's cleaned up later
2. the execution that noticed the prior execution and then actually raises an InterruptError

I will go change Execution #1's cleanup to say it's an InterruptedError (note the -ed) to maybe help differentiate. To be clear, that error will never be raised nor rescuable in Ruby, it's just added later as data to the database record.