I’m aware of the async job and how it moves to dead letter.
My questions is regarding going ahead with synchronous tasks and if something fails, then how to make sure we don’t re-execute the service tasks which were executed succesfully.
For example:
wait state 1 → make API call (service task1) → send email (service task 2) → wait state 2
When my flow moves from wait state 1 followed by executing service task 1 successfully but fails sending email i.e. service task 2. Then my flow will come back to wait state 1.
Now if I re-trigger the flow from wait state 1 , how can I avoid executing service task1 and just going ahead with task 2 which failed earlier.
is there something I can do?
Please let me know.
@joram May I pls have some feedback on this pls. sorry, if tagging ins’t allowed
You can’t handle this when doing it synchronously. When there is a failure, Flowable is going to rollback the transaction.
You have one of the following options:
Use Boundary Error Event
On your service tasks configure the handled exceptions and use BPMN Boundary Error to navigate if an exception happens
Use Async (Leave)
When using async or async leave service tasks then the transaction boundaries change. e.g. if your email task is async, then if it fails the transaction will only rollback prior to the execution of the email. If it is async leave then if the next task fails the transaction will rollback just after sending the email (it won’t retry the email).
it’s fine if it’ll rollback.
I’m talking about the scenario where I wake up the workflow from the waiting state it rolled back to.
I do not want to re execute the task1 as it was succesful earlier and go to service task 2.
I guess I can do this by setting a task variable at the end of the task execution indicating it’s done.
So, when we try to re-execute it, we’ll check that variable was true and skip the task.
That’s more or less what I meant with the “Use Boundary Error Event” section. Keep in mind that just setting the variable isn’t enough, as if the transaction rolls back, the variable update will not be persisted in the DB.