i tried to set the possible retries of a job via camunda:failedJobRetryTimeCycle.
I try to achieve that a failed job is not retried but a incident is directly created.
I attached a simple process which demonstrates the problem.
The service Task has a failedJobRetryTimeCycle of R5/P3M so the job should have a retry of 5. When executing it in a test case the job has a retry of 3.
I debugged this and found out that the expression is first evaluated at execution time of the job.
So if you check the retries of the created job, the returned value will be every time 3, since it is the default retry count.
But at job execution the expression will be evaluated and the correct retry count is set and used.
See the code in the FoxJobRetryCmd.
Thanks for your reply but I still think it does not work.
See my failing testcase. In this example the retry count should be 4 (R5/P1M) after the exception from service task is thrown but it is 2.
your test case works for me. I used the process model, which was uploaded from you before.
As delegate for the service task is used a Java class that throws an exception if executed.
Is it possible that you create a test project, which contains the failing test case and the corresponding resources,
so we can reproduce the problem.
See for example this unit test template from thorben.
I analyzed the problem best on the unit test template.
My embedded process engine did not set the FoxFailedJobCommandFactory + ParseListener but the unit test template does so the retry was only set to specified value when executing test with unit test template.
I added this code to my embedded process engine
List<BpmnParseListener> parseListeners = new ArrayList<>();
parseListeners.add(new FoxFailedJobParseListener());
conf.setCustomPostBPMNParseListeners(parseListeners);
conf.setFailedJobCommandFactory(new FoxFailedJobCommandFactory());
Now it works but I found no documentation that this is a necessary step.
I also had trouble as I wanted to tune the camunda:failedJobRetryTimeCycle property of some (service) task in my BPM to prevent any retry.
Until I found out after some intensive debugging session, that it requires me to set R0/PT5M or similar on my task (not just R0 nor R0/) and to place a safe-point before the same task (asynchronous before continuation enabled).
Maybe this hint helps you.