Default retries for external task

Camunda 7.9 - Spring Boot
Using External Task via the rest api the ‘retries’ field is always null, as I read the documentation I understand that this number should be a default 3

I’ve implemented the following without affect - Job Execution : where is retry cycle configuration?
Also tried this without affect -
< process-engine name=“default”>
< properties>
< property name=“failedJobRetryTimeCycle”>R5/PT5M
< /properties>
< /process-engine>

However in all cases when retrieving a task from fetchAndLock, the retries is null.
What should the default case be and how to implement R5/PT5M ?


Looking through the code i see that the above options only applies to Jobs and is correctly applied, however the retries is never propagated to the External Task when created, and so is always null (for external tasks)

Is there no way to set a default retries for External Tasks ? Only from the external task client?


I’d like to second the request.

In the The Job Executor manual about handling of failed jobs there is following example:

<serviceTask id="failingServiceTask" camunda:asyncBefore="true" camunda:class="org.mycompany.FailingDelegate">

I’d tried to recreate it by adding Asynchronous Before/After and specifying proper Retry Time Cycle parameter that is well represented in Camunda Modeler UI:

This is properly represented in BPMN XML

<bpmn:serviceTask id="Activity_1bh3caw" name="Test" camunda:asyncBefore="true" camunda:type="external" camunda:topic="service">

however both retries field in external task objects provided by /external-task/fetchAndLock is 0 and after task submits /external-task/{id}/failure no retry is attempted after the 5 minute deadline specified in the BPMN.

Is this missing feature, or incomplete documentation about failedJobRetryTimeCycle being ignored for <serviceTask type="external" ...>?

Hi - can you provide the payload you are sending to /external-task/{id}/failure? I don’t think you can set the “Retry Time Cycle” property in the .bpmn diagram for external tasks as that service has to be told be something outside of the process whether or not the task was successful, and thus whether or not to retry. The failure needs to be handled by the worker or via the REST API that you mentioned, so if the call to /external-task/{id}/failure is not working, then I would be interested to see the request you are sending as that should work.