Can you override RetryTimeout?

When we fail an external task, we set the RetryTimeout to X minutes. Which means the external task cannot be fetched-and-locked until X minutes has elapsed.

After an external task has failed, is there a way to modify the external task so that it can be fetched immediately, without having to wait for the X minutes to transpire, using REST? Or can we have the fetch command ignore the RetryTimeout?

I tried resetting the Retry count. I tried failing the task and then using the “Increment Number of Retries of Failed Jobs” feature, but neither of those allows the task to be fetched immediately, we still need to wait until the X minutes has elapsed since the task last failed.

I cannot even find how we can view how much time is left before the external task can be fetched

The use case is that sometimes we don’t want to wait X minutes for the next attempt to run the external task.

We are using Camunda version 7.14
With Springboot
Our code uses using REST calls for fetching external tasks and Completing or Failing them.

Thanks

Hey @MarkyMark2000 ,

If the external task fails, it can send with the failure the retryTimeout itself. So best would be to define it in the logic of your external task. So in cases you want to wait the external task sets the retryTimeout to xx time and in cases where you don’t want to wait the time can be set to 0.

Would that work in your case?
Nele

@Nele

We are setting the RetryTimeout in the logic of our external tasks. We set it for a long period of time. In most cases, this long period of time is ok. But sometimes when we can fix the underlying problem very fast and then we want to have the external task run right away without have to wait for the long period of time to elapse.

We don’t want to set the RetryTimeout to a shorter period of time because most of the time it would be a waste of resources to keep retrying frequently.

Hey @MarkyMark2000 ,

okay I see. Have you tried to send an unlock call ? I just tried it and I think it works. At least I can fetch the task with a different worker afterwards again.

I hope that helps
Nele

@Nele the unlock and it worked.

Thanks.

It wasn’t intuitive that that would do it. Is it because it’s clearing the worker id that it works?