Call activity retries not working?

Hello! I’ve faced a certain problem that stunned me.

I have two processes: processA.bpmn and processB.bpmn

  1. processA launches a call activity that starts processB with input variable.
  2. processB interacts with an external api and does such actions:
    a. Get dictionary element by id and saves it to context at variable “element”
    b. Get variable “element” from context, update it’s content and update “element” variable at context
    c. Get variable “element” from context & update it by rest client at external api (PUT) method

There is a problem - external api can’t be reached or i can get 409 on its update, so i need to retry the whole processB entirely. ProcessA call activity has a custom retry time cycle of R5/PT1S to make fast five attempts. So if i fail to update dictionary element at processB activity “Update dictionary element” i throw an error and expect call activity to make a camunda retry, but it doesn’t.

What am i doing wrong? How should processB behave to launch a camunda retry on call activity “Launch update dictionary” at processA?


Hi @Orange256,

Retry strategies concept is related to incident management which is handled by camunda. (In case of service task failure, configured retry strategy to be used and incident to be created once all automatic retries get consumed.)

No need to throw BPMN Error. BPMN Errors can be used in case of business errors or handling errors via the process.

https://camunda.com/best-practices/dealing-with-problems-and-exceptions/#handling-exceptions-via-the-process

I believe that what we have here is considered as technical error and can be handled directly by camunda.

https://camunda.com/best-practices/operating-camunda/#modeling-for-easier-operations

so in short, remove BPMN Error logic from your model. And since you need the whole called process to get recalled in case of service tasks’ failure then tick async before for the call activity only (not for service tasks)

This works fine, except one thing - call activity “Launch update dictionary” throws no incident. That’s an important moment at my process, because all incidents are handled manually

Hi @Orange256,

Can you please share your model…

Hi @Orange256,

Once all automatic retries get consumed, an incident should be created.

I am going to share a working example shortly.

Hi @Orange256,

Kindly find attached working example (war process application)
my-process-app.war.txt (53.8 KB)

Below is a snip showing the created job for the failing activity and the remaining # of automatic retries. (no incidents created yet)

Below is a snip showing the created incident after all automatic retries got consumed.