> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Recover from drift or a partial apply
description: >-
  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.
route: /docs/compute/configure/drift-and-partial-apply
page_id: docs-compute-configure-drift-and-partial-apply
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Compute administrators whose configuration change stopped partway
voice: D
reader_question: My configuration apply stopped partway. What actually changed, and what do I do next?
primary_action: Get help with a configuration conflict
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-configure-drift-and-partial-apply-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## 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.

[Get help with a configuration conflict](/help/compute/configuration-conflict)