Error handling strategy with Java

Training
1

I completed the course.
But I think there is an error in the solution for the saga approach.
The solution shows the revert actions are added BEFORE the action to be rolled back is executed, like

 saga.addCompensation(activities::revertInventory, order);
 String inventoryResult = activities.updateInventory(order);

However, that would mean that when the updateInventory activity fails, the revertInventory action is executed. I would expect when the activity fails, no changes have been made and nothing needs to be reverted.

If I am wrong, how is the revert action informed the related task was not executed ? Do I need to discover that myself based on p.e. database state ?

Regards,
Wim Veldhuis

2

This is a very good question. The answer depends on the semantics of action failures. If you expect that an action will only throw an exception when it can guarantee that no side effects requiring reversal were produced, then it is acceptable to add a revert action afterward. This implies that all non-business failures must be retried as long as they continue to occur.

However, if there is a limited time to complete the entire SAGA — for example, when a user is waiting for the result — you cannot guarantee that the action will be retried as long as necessary. You might end up in a situation where the action produced a side effect, but the successful response did not reach Temporal. In this case, you must add the revert action before the action and ensure that the revert action is robust against the possibility that the action was never performed when compensation is triggered.

3

What I am basically expecting is that when the action fails, no revert is necessary.

But there is an edge case, where the action did succeed, but the result did not yet reach the workflow. This only seems to be something for time limited workflows, where the action was aborted during the small time frame of completion and notifying the workflow. I would not expect that to be the default shown in the course without further explanation. This could be made more clear.

I would think it would occur far more often that the activity fails, and in those cases the revert action does not need to be able to determine if a rollback is required if it is registered after the action completed.

I researched a bit and it is possible to have state used as parameter in the revert action to be determined at call time. This requires a method to return the actual value (defer determining the value until runtime, not registration time.
I think that would also be a useful extension to the course to explain when the parameters are evaluated for the call. It seems that if you use a variable, the value of the variable is taken at the moment of the registration.

I will keep that in mind when we need to use this.