Update variables on BPMN error

[jwulf]

At the moment you can't implement a retry loop with a timer that is entered via a BPMN error throw and has decrementing retries:

What I'd like to be able to do is this:

However, there is no opportunity to mutate anything when throwing a bpmn error from the client....

[jwulf]

If you could mutate with the error throw, you could even do a back-off retry in the worker.

[saig0]

Is this request only about providing a timeout before a failed job is retried?
If yes then this may be better implemented directly as part of the FailJob command (#164) instead of modelling it (maybe multiple times) in the workflow.

[berndruecker]

For the issue at hand I do agree, that the increasing retry interval should be baked in the retrying of the service task itself (but probably we could have out-of-the-box support for that in future). It is not an error with any business reaction (that's what BPMN error events are for), but a technical problem that will probably be solved by retrying or end up with an incident. This should in general not be modeled. I thought I can easily point to a BP - but I think we should probably add this rule of thumb there: https://camunda.com/best-practices/dealing-with-problems-and-exceptions/#_distinguishing_between_strong_exceptions_strong_and_strong_results_strong

Adding payload alongside the error seems like an interesting option - but not related to this problem IMHO.

[ezolnbl-dpc]

👍 +1 to adding variable content for errors

[skayliu]

Hi, @jwulf @saig0 @berndruecker, When throw error with variables, the variables will first been setted at the local scope of the job's associated task, then to the error event scope and last to the process scope. What you think?