Test agent checkpoints before relying on recovery

Identify what the checkpoint actually preserves

LangGraph documents checkpoints as thread-scoped state, distinct from its cross-thread store. Rubrex recommends writing a recovery inventory for the chosen runtime: messages, pending tool requests, approval records, document versions, and references to external operations. Name the authoritative owner of each field rather than assuming the checkpoint contains the whole application.

Use a synthetic order assistant that reserves one test item. Record a reservation identifier independently of conversation state. Specify what recovery should mean after a process restart: either return the confirmed reservation or reconcile an unknown outcome before issuing another reservation.

Evidence: LangGraph: Persistence [1]

Put the interruption beside the external commit

Create three controlled interruption points: before sending the reservation, after the service commits but before its response arrives, and after the response arrives but before local state is persisted. Capture the checkpoint version and service ledger for each interruption. Restart from the same intended thread, then observe actual service requests.

The middle case matters because the agent can honestly have no confirmation while the service has already changed state. Recovery must inspect the operation identifier or enter an explicit uncertain state. Repeating the request blindly tests retry behavior, not reliable checkpoint recovery.

Check restoration without hiding incompatible state

Inspect the resumed task identifier, tool arguments, accepted result, and pending next step. Add a separate trial with a changed state schema or unavailable referenced document. The useful outcome may be a controlled migration or a refusal to resume; silently replacing missing fields with plausible defaults can lose the original transaction meaning.

Keep a legitimate uninterrupted control and an interrupted read-only task. These distinguish a broken restart environment from failures specific to external writes. Count successful recoveries by interruption class, retaining uncertain and failed runs in their own categories rather than reporting only resumed conversations.

Choose a recovery boundary the team can support

Release resumable execution only for operation types whose final state can be reconstructed. For the reservation example, a single ledger entry and one acknowledged outcome are acceptance requirements. If a tool cannot expose completion status, pause the workflow for reconciliation instead of letting the model infer what probably happened.

Retain restart logs, checkpoint and schema versions, service receipts, and the reconciliation decision. Re-run these cases after changing persistence, tool adapters, or approval logic. A checkpoint feature is useful infrastructure; the proposed drill establishes how one concrete workflow behaves at the moments where its state can diverge.

Common questions