Replies: 2 comments
-
|
+1 on this. Having a first-class Saga utility in the SDK - even a lightweight one like the @Compensable decorator + context manager proposed here would meaningfully help customer adoption, as saga/compensation is one of the most common patterns that comes up when enterprise customers evaluate DF for multi-step workflows. The proposed implementation is the right level of abstraction: thin enough to not constrain unique requirements, but saves every customer from reinventing the same boilerplate. |
Beta Was this translation helpful? Give feedback.
-
|
docs improvement suggestion while we discuss what htis might look like |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
What would you like?
Summary
It would be helpful to have a first-class way to define compensating (undo) actions for steps when building workflows with DurableContext. The idea is to support a simple, Saga-style pattern using:
This would let users build multi-step workflows with clear, structured rollback logic without reinventing this pattern in every project.
Motivation
When orchestrating multiple side-effecting steps (e.g., create order → charge payment → ship), users often want sagas: if step N fails, we undo steps N-1, N-2, … in reverse order.
Right now, users can implement this manually with DurableContext, but:
A small helper + decorator would provide a consistent, ergonomic pattern and encourage best practices (idempotent compensations, durable compensating steps, etc.).
Possible Implementation
Proposed API / Approach
1.
@compensabledecoratorAllow users to define a step and its compensation in one place:
Usage:
2. Saga helper built on top of
DurableContextSaga wraps context.step(...), automatically registers compensations, and runs them on failure. Internally, each compensation is also executed as its own durable step for observability and retries.
Example usage in a durable function order workflow
If any step raises an exception, the Saga context manager will:
Execute registered compensations in reverse order, each as its own step.
Re-raise the original exception so the workflow’s failure behavior remains consistent.
Notes / Considerations
Is this a breaking change?
No
Does this require an RFC?
No
Additional Context
PM for the feature. Several users pinged me directly asking for this.
Beta Was this translation helpful? Give feedback.
All reactions