Job Executor get Retries() method always returns '3' the first time.

camunda / camunda-bpm-platform

Flexible framework for workflow and decision automation with BPMN and DMN. Integration with Quarkus, Spring, Spring Boot, CDI.

Apache License 2.0

4.12k stars 1.56k forks source link

This issue was imported from JIRA:

Field	Value
JIRA Link	CAM-9486
Reporter	QP676Nj What is this name? This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Has restricted visibility comments	false

Reference in the forum: https://forum.camunda.org/t/job-executor-getretries-is-wrong-in-some-cases/9470/5

The first time a task is executed under a job, it is getting a false number of retries left. That's misleading. Example with a script Task in groovy:

jobExecutorContext = Context.getJobExecutorContext();
println jobExecutorContext.getCurrentJob().getRetries();
throw new Exception("...");

And in the task fields I set Retry Time Cycle to be: "R10/PT10"

Expected: In the log, the first time I get a number that shoud be consistent with the retry cycle I set for the asychronous task 10 ... (Exception) 9 ... (Exception) 8 ... and so on until 1.

What currently happens: the first number is always '3'. 3 ... (Exception) 9 ... (Exception) 8 ... and so on until 1

Links:

Solution idea: evaluate the cycle already when creating the job

Pros

Behavior is more intuitive.

Cons

Additional database queries on creating jobs lead to a higher load: the process definition (when not cached), execution, and variables (to resolve expressions containing variables) must be queried to get the failed job retry configuration from the activity, parse, and evaluate it.

Further implications

User might rely on the previous behavior (should we make the new one configurable?)
To avoid incidents being raised prematurely and to preserve the previous behavior, the expression R0/PT30S should lead to an initial retries count of 1.
The variables for resolving the expression might only exist after the job fails for the first time (variables are created when a service is unavailable and an exception is thrown).

Conclusion

The effort to build it is relatively low, but we should emphasize writing tests for some more edge cases.
We should make it configurable and opt for the previous behavior as default since additional queries could slow down the process execution, and the further implications can break the expected behavior of process applications.

Prototypical implementation

https://github.com/camunda/camunda-bpm-platform/tree/2300-fix-initial-retries

camunda / camunda-bpm-platform