Job Executor getRetries() is wrong in some cases?

Camunda 7 Topics Discussion & Questions
1

I set in bpm-platform.xml the following property:

<property name="failedJobRetryTimeCycle">R1/PT1S</property>

After this setup, every async script and async service task will not retry to execute, as expected.

But I have the problem in getting the correct retries from job executor.

The code in the script(groovy) Task is this:

import org.camunda.bpm.engine.impl.context.Context

def jobExecutorContext = Context.getJobExecutorContext();
if (jobExecutorContext!=null && jobExecutorContext.getCurrentJob()!=null) {
  // this is called from a Job
  def j =  jobExecutorContext.getCurrentJob()
  println "Remaining Retries: ${j.getRetries()}" //  <----------------- THIS PRINTS '3' instead of '1'(or 0)
} else {
  println "No Job found"
}
throw new Exception("Errore di TEST")

The remaining retries are always 3 instead of 1, and it’s not attempting any other retries (and it’s in fact the expected behaviour, I don’t want retries by default)

there’s something I’m missing?

2

Another test:
Suppose the property in bpm-platform.xml is set like that:

<property name="failedJobRetryTimeCycle">R5/PT10S</property>

The same process will output this weird thing:

Remaining Retries: 3     <---- THIS SHOULD BE '5'
Remaining Retries: 4     <---- FROM NOW ON IS CORRECT
Remaining Retries: 3
Remaining Retries: 2
Remaining Retries: 1

UPDATE: the same is happening if the retry cycle is set locally to the async task/script. The first result is always 3!

3

Your observations are correct. Any retry configuration is only evaluated once the job has failed, so before the first failure, the retries field shows the default value which is 3.

4

Yes, but it’s kind of misleading. It should be changed. Otherwise I have to detect if the job has already failed once to know for sure I’m getting the right value.

5

Feel free to raise a bug issue over at https://app.camunda.com/jira/browse/CAM. Code contributions are always welcome :slight_smile:

1 Like
6