[19.0][IMP] edi_queue_oca: cancel wait_dependencies jobs on exchange failure

[AaronHForgeFlow]

When a chained queue job (such as generate->send or receive->process) fails, downstream dependent jobs remain permanently stuck in wait_dependencies because queue_job only cancels dependent jobs upon explicit job cancellation.

Ensure _job_on_fail_update cancels any wait_dependencies queue jobs belonging to the errored exchange record so zombie jobs do not linger.

[simahawk]

If I get it right, when a send job fails you will cancel it... I don't think this is ideal at all.
If you cancel it, you'll miss it and you won't be able to re-schedule it.
Am I missing anything?

[AaronHForgeFlow]

This targets only downstream child jobs in state wait_dependencies (for example, the chained send job when generate has failed) When generate fails, the child send job is stuck in wait_dependencies waiting for its parent generate to reach done

should I mark the job as failed instead?

[simahawk]

I see this useful only in the situation where a second pair of jobs does the work and leaves the old ones stale:

• job11: generate -> fails
• job12: send -> stale
• job21: generate -> done
• job22: send -> done

If I get it right, with your change as soon as a generate fails, the send will be discarded leaving only the generate job in failed state. If you run only this job, no send will happen unless you also rely on crons but that can cause additional delays. Correct?

should I mark the job as failed instead?

only if requeueing the generate job causes the requeueing of the chained job too (which I doubt).

[AaronHForgeFlow]

If you run only this job, no send will happen unless you also rely on crons but that can cause additional delays. Correct?

Yes, correct. In my case I usually rely on the user action, they will create a new exchange record leaving the previous one as canceled or failed. I am open to suggestions, I am not sure if this is the best approach.

[simahawk]

TBH I don't have a precise answer. Options:

1. when a full process is over input/output can spawn a GC job to cancel stale jobs for that record
2. add GC to the existing crons to cancel stale jobs
3. any other option?

I tend to say that opt 2 is the cleanest and safest.

[AaronHForgeFlow]

Added a system parameter so the zombie jobs can be collected some time. If this is too aggresive maybe we can add a configuration or a new field in the backend so it does not affect current instances.

[simahawk]

LGTM

[simahawk]

@AaronHForgeFlow time to add yourself? :)