Compute
Recover from drift or a partial apply
An expired plan, a changed resource version or an external timeout can stop an apply midway. Verified changes stay in place, so resume or replan instead of assuming a rollback happened.
Read the per-resource states first
An apply that stops is not an apply that undid itself. Verified changes stay in place, and each remaining resource carries its own state and its own next action.
Start by reading the per-resource states, not the aggregate. PARTIAL_WITH_NEXT_ACTION tells you the change is incomplete; only the resource states tell you what is true.
There is no global rollback. Assuming one is the fastest way to apply a change twice.
Match the symptom to the cause
| What you see | What happened | What to do |
|---|---|---|
Aggregate EXPIRED | The plan aged out before the apply finished | Inspect, replan, apply the new plan |
Resource CONFLICT | The resource version moved since your plan | Inspect that resource, replan it |
Resource RETRYABLE | A transient failure, often an external timeout | Send the same apply again |
Resource APPLIED_UNVERIFIED | The write happened, the read-back has not confirmed | Read back again before doing anything |
Resource REVOKED | The authority behind it was withdrawn first | Restore authority, then replan |
Resource ROLLED_BACK | That one resource returned to its prior value | Read it back and decide whether you still want the change |
Handle an expired plan
A plan carries a validity window. Once it closes, the apply stops and the plan cannot be revived.
Inspect current state, build a new plan, and read it. Resources that already verified will show as ALREADY_MATCHED in the new plan, which is how you confirm they survived.
Do not reuse the old plan identifier or its digest. The digest binds an apply to bytes that no longer describe your account.
Handle a changed version
Every mutable resource carries a non-decreasing version. If someone else changed the resource after your plan was built, your apply sees CONFLICT and stops on that resource.
That is the guard working. Inspect what changed, decide whether your desired value still makes sense, and replan.
A late or stale attempt cannot advance state. Retrying an old apply against a moved resource will keep refusing until you replan.
Handle an external timeout
A source or destination in your own systems can time out. The resource returns RETRYABLE, and the same apply is safe to send again.
Exact replay returns the prior result rather than duplicating an effect. The same identity with a different payload is refused as equivocation.
If retries keep timing out, test the source or destination on its own before you touch the configuration again.
Understand what "rollback" does not cover
ROLLED_BACK applies to a configuration value returning to its prior state. It never reaches outside the account.
An invitation that was sent stays sent; remove the membership instead. A result written to your warehouse stays written; write a corrected result. An invoice that settled stays settled; raise an adjustment.
Repair those forward. Waiting for a rollback to reverse them means waiting for something that will not happen.
Confirm recovery, or ask for help
Re-run the read-back until every resource reports VERIFIED or ALREADY_MATCHED, and the change reports COMPLETE.
Keep the receipt reference from the final apply. It records which resources changed, which were already correct, and when.
If a resource keeps refusing, quote that receipt reference and the state you are seeing. Never send a key, a signed URL, bank details or a copy of your input.