Job Executor getRetries() is wrong in some cases?

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?

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!

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.

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.

Feel free to raise a bug issue over at Code contributions are always welcome :slight_smile:

1 Like