Hi,
I want to use the ManagementService#setJobRetries method to recover jobs that have failed three times due to e.g. an exception in a service task. In my case, the retry counter has been decreased to zero so that the async executor does not pick them up.
Now, when I use the setJobRetries method to a value > 0, I thought that the async executor would pick the job up after some time. However, this does not happen in my case. As far as I understand the code, this is a general issue with the setJobRetries method as it always seems to write back the JobEntity with a duedate=null. This is not obvious to see, however my debugging showed that when the JobEntity is read in SetJobRetriesCmd, the duedate attribute is always null. Looking at the mapper information in Job.xml, I see that the duedate attribute is included in the messageResultMap structure. It is only there for timerResultMap. This would explain the observed behavior.
Can this be considered as a bug? or is there any other workaround?
Best regards,
Stefan
Hi Stefan,
Are you using Flowable 5 or 6?
Best regards,
Tijs
Good point 
I missed that. We are currently on 5.21.0. Comparing the Job.xml to version 6, I can see significant changes in this area
Yes indeed in 6, I would expect this to be an issue because we’ve changed the jobs table in 4 different tables there 
For 5 this should indeed work. I’ll see if there is already a unit test for this and check if the due date is set to null, because that shouldn’t be the case.
Thanks,
Tijs
Hi Tijs,
any updates on this? I was searching a bit through the tests, but I only found some unit tests which do not test the whole stuff end2end.
Best regards,
Stefan
Hi Stefan,
Yes, I was able to reproduce the issue in a new unit test. I also have a fix ready, but wanting to do a bit more testing first. I hope to have a solution pushed tomorrow.
Best regards,
Tijs
Hi Stefan,
The issue should be fixed now with the following commit:
There’s a new unit test explicitly testing the set job retries logic.
Best regards,
Tijs