Retry with waiting time and non-stop flow

Hello, everybody.

I have been trying a few things involving retry techniques, however, I couldn’t find the better way to do it. So I would like to ask you to give me possible solutions that are better and prettier in Spring Boot with Camunda.

Problem: We have a sequence of service tasks that will do some kind of different registrations depending in the conclusion of the previous one. These service tasks will possibly fail, and when this happens, we need to check if it did not reach the maximum retry times, and if it is ok, it should wait for N minutes to retry the service task. And the following service task cannot start before a success of the previous one been give. PS: It has to be synchronous and cannot stop the flow.

If you guys could share with me the way you would do it, I would be delighted.

Thank you all.

Best Regards.

Heloisa Carbone

When you say synchronous - you mean they must all run in one transaction?

I couldn’t say that is in one transaction, because if the second service task fail, the previous one shouldn’t be replayed, just the second one, and even if after the N retries if it fails, the system will sent a notification to infrastructure, where someone manually would choose if it should retry again, or just skip it.

However, they can’t happen at the same time, due to client issues.

If you wanted the process to be synchronous it means that would run in one transaction so that if anything failed then everything would be rolled back.

But i’m getting the impression that you would actually like asynchronous behavior which would mean that if one fails - it wouldn’t roll back anything that happened previously, instead it would just retry the failed task a certain number of times.

is that correct?

Not totally, because if it is asynchronous, it will start the following service tasks before the previous one has been finished.

Following is an example of the theory of what should happen:

The markdown would be the retry with time. The blue pen is the flow when the service task of the exec 1 is success, and after this the Exec 2 starts it’s execution.

I think you’re confusing parallel execution with synchronous execution. In this context synchronous would mean that they will be executed one at a time in order but that any failure would result in a rollback of all completed tasks.

I see you’ve basically modeled a retry strategy for each task - you can achieve this without needing to model it. if you tick a task as asynchronous you’ll have the ability to then add a rety cycle.
In the case below it would retry 4 times every 5 mins after which it would create an incident and hold the state until someone either fixed it or cancelled it.

Maybe, I might be confusing some definitions.

However, if I use the Asynchronous Continuation, the second service task will be executed before this one has been finished, if it has a problem and has to retry, right ? Or am I wrong ? Because I’ve tried this approach, nevertheless it never waited, it executed the second without finishing the other and debugging I could check, that it still was retrying the first one.

There is no way this should be able to happen.
The process will only process if the logic of the task has been successfully completed.