Compensating Workflows Pattern #4665
Open
+189
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Cassandra Coyle <[email protected]>
Signed-off-by: Cassandra Coyle <[email protected]>
This was referenced Jun 5, 2025
|
@marcduiker - Let's think over a diagram we could add into the docs and presentation deck |
marcduiker
requested changes
Jun 19, 2025
There was a problem hiding this comment.
I've created a diagram for this, but this will be part of another PR since I want to update all the workflow related diagrams #4679 .
| @@ -1386,6 +1386,195 @@ func raiseEvent() { | |||
|
|
|||
| External events don't have to be directly triggered by humans. They can also be triggered by other systems. For example, a workflow may need to pause and wait for a payment to be received. In this case, a payment system might publish an event to a pub/sub topic on receipt of a payment, and a listener on that topic can raise an event to the workflow using the raise event workflow API. | |||
|
|
|||
| ## Compensation | |||
|
|
|||
| The compensation pattern provides a mechanism for rolling back or undoing operations that have already been executed when a workflow fails partway through. This pattern is particularly important for long-running workflows that span multiple microservices where traditional database transactions are not feasible. | |||
There was a problem hiding this comment.
Suggested change
| The compensation pattern provides a mechanism for rolling back or undoing operations that have already been executed when a workflow fails partway through. This pattern is particularly important for long-running workflows that span multiple microservices where traditional database transactions are not feasible. | |
| The compensation pattern (also known as the saga pattern) provides a mechanism for rolling back or undoing operations that have already been executed when a workflow fails partway through. This pattern is particularly important for long-running workflows that span multiple microservices where traditional database transactions are not feasible. |
| ctx.getLogger().info("Order shipped: {}", shipmentId); | ||
| compensations.add("CancelShipment"); | ||
|
|
||
| // Step 4: Send confirmation |
There was a problem hiding this comment.
I suggest to remove this activity. It's a bit confusing now if the SendConfirmation throws, then the rest is still compensated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adding docs for a new workflow pattern: compensating workflows
I added a java example here. This is just a first pass implementation that could be improved upon, but wanted to document the new pattern
@hhunter-ms can you add a diagram to my PR and tweak it as you see fit?