Compensation: undo the steps that succeeded when a run is abandoned
- Dominant language
- C#
- Stars
- 6
- Forks
- 7
- Avg merge
- 4h 21m
- Merged PRs (30d)
- 307
Description
A workflow that posts an accounting entry and then fails at the next step leaves the money moved and the paperwork missing. Nothing undoes the entry, and nothing records that the business is in a half-applied state.
The run record already knows exactly which actions succeeded. That is the hard half, and it is built. What is missing is the instruction for what to do about it.
## What to add
A `Compensate` field on an action, naming a request definition or an action to run if the run is abandoned. On a permanent failure of a `Halt` action, or when an operator abandons a run, walk the succeeded actions in reverse and run each one's compensation.
## What has to be decided first
**Not everything can be undone, and pretending otherwise is worse than not trying.** An SMS cannot be unsent. A partner API may have no void. Compensation has to be declared per action, absent by default, and a run whose compensation is incomplete has to say so rather than report itself cleanly rolled back.
**Compensating actions need idempotency too.** The compensation runs under the same at-least-once runner as everything else, so it needs its own stable key. This depends on the connector idempotency issue.
**Order.** Reverse order of success is the usual rule and is right here.
## Sequencing
This should come after action outputs and the failure policy. Halt is what creates the moment where compensation is needed, and without outputs a compensation often cannot address the thing it is undoing, because it does not have the provider's reference for it.
## Done when
- An action can declare a compensation, and it runs in reverse on abandonment.
- An action with no compensation declared is reported as not compensated, not as fine.
- A run whose compensation partially failed is visibly in that state.
Contributor guide
Research direction
Start by reading the existing run record and the action, outputs, failure-policy, and connector-idempotency work referenced in the issue. Define the compensation behavior for abandoned runs and permanent Halt failures, including reverse success order and stable idempotency keys. Done means declared compensations run, undeclared actions are reported as not compensated, and partial compensation failure remains visible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100