LangGraph Checkpoint Recovery Interview Scenarios

Checkpoint recovery is where an agent graph meets distributed-systems reality. A state snapshot can help execution resume, but it does not prove that the snapshot is correct, that the next node is safe to run again, or that an external side effect happened exactly once. Senior candidates must reason about all three boundaries.

These 20 scenarios test state ownership, thread isolation, deterministic resume, side-effect reconciliation, schema change, and recovery evidence. The best answers inject failures at known points and verify both graph state and the outside world rather than merely checking that an invocation eventually returned.

Model Recovery as a State Transition

LangGraph's persistence documentation describes checkpointers as thread-scoped state persistence and stores as application-defined data that can span threads. Its testing guide shows controlled state updates and execution from selected graph regions. Together, those capabilities support precise recovery tests when the application defines safe boundaries.

An interviewer should ask, "What has already become true outside the graph?" before accepting any retry answer. That question exposes whether a candidate understands the limit of checkpoint atomicity.

Define Checkpoint and Thread Contracts

1. Why must a recovery test assert the checkpoint contents, not only the final answer?

The same final answer can emerge after duplicated tools, lost approvals, or corrupted intermediate state. I would inspect the thread identity, state values, pending next node, checkpoint metadata, and history at the injected failure. Then I would resume and assert the expected transition. State-level evidence localizes the defect and verifies that recovery began from the intended boundary instead of silently restarting the entire graph.

2. How would you generate and protect thread identifiers?

Use an opaque identifier scoped to the authenticated conversation or workflow, validate its format, and authorize every read or resume against the owning principal. Do not derive it from raw personal data or trust a client-provided value without ownership checks. Tests attempt cross-user reuse, missing IDs, stale IDs, and concurrent access. Stable thread identity enables continuity, but predictable or unscoped identity creates a state disclosure and corruption risk.

3. What is the testing consequence of confusing a checkpointer with a store?

Thread recovery tests may accidentally depend on cross-thread memory, or shared preferences may be expected inside a checkpoint where other conversations cannot see them. I would specify each state field's scope and retention, then test a new thread for intended isolation and shared-store access separately. The distinction affects deletion, authorization, and migration. Treating both as generic memory obscures who owns data and which recovery path can legitimately read it.

Recover From Controlled Failures

4. How would you test a failure immediately before a tool node?

Inject the fault after the routing decision but before the tool call, then inspect that the checkpoint records the intended next node and no external request exists. Resume with the same thread and assert one tool invocation and the expected state update. This boundary should be safe to retry. A test that fails earlier or later proves a different contract, so fault location must be observable and deterministic.

5. How would you test a failure immediately after a tool succeeds?

Make the tool record an idempotency key and result in a fake or controlled service, then fail before graph state confirms completion. On resume, the node should reconcile the existing operation or safely repeat it under the same key, not create a second effect. Assert external call history and final state. This is the dangerous ambiguity window where a checkpoint alone cannot tell whether the remote commit happened.

6. What would you do when a checkpoint contains valid state but an invalid next-node decision?

Quarantine the thread from automatic resume, preserve the snapshot, and determine whether routing logic, state schema, or a manual update caused the mismatch. Use a reviewed repair that writes corrected state with provenance, then resume in a controlled environment. Skipping directly to a later node may violate invariants. Recovery speed matters, but an invalid control decision is not made safe merely because its fields deserialize.

7. Why should cancellation be tested separately from exceptions?

Cancellation may interrupt awaiting work without following the same error handler or state update path as a thrown exception. Test cancellation before dispatch, during a remote call, and during streaming output. Verify checkpoint closure, pending work, client-visible status, and effect reconciliation. Treating cancellation as ordinary failure can leave a thread resumable while the client believes it stopped, or can discard completed remote work that must be acknowledged.

Make Side Effects Idempotent

8. How would you design a payment-like tool node for resumability?

Create an operation identity before dispatch, persist it in graph state, send it as the external idempotency key, and record the provider result or lookup handle. On retry, query or repeat under the same key and map the existing result into state. Never generate a new key inside each attempt. This adds reconciliation logic, but it is necessary because graph persistence and the remote system do not share one transaction.

9. What evidence proves a recovered email action was not duplicated?

Use a controlled mail adapter that records message operation ID, recipient hash, template version, and accepted provider identifier. Fail around the send boundary, resume, and assert one logical operation even if transport attempts repeat under the same key. User-visible inbox inspection can supplement but is slower and less deterministic. A final graph flag such as email_sent=true is insufficient unless linked to external acceptance evidence.

10. When is compensation safer than retry?

Compensation is appropriate when the original effect is confirmed, cannot be idempotently replayed, and the business process defines a safe reversal or follow-up. For example, release a reserved resource rather than reserve it again. The graph should record both original and compensating operation identities and route uncertain cases to review. Compensation is not generic undo; some effects are irreversible, and automatic reversal can create a second harmful action.

Test State and Partial Execution

11. How would you test a graph region without executing earlier expensive nodes?

Compile with a test checkpointer, seed state as if the preceding node completed, identify that node as the state source, and invoke the same thread through the target region with a controlled stop. The official testing guide demonstrates this partial-execution pattern. Validate required state invariants before starting so the test does not create impossible snapshots. It improves speed and fault targeting, while end-to-end tests still cover real checkpoint creation.

# Illustrative partial-recovery test structure; align imports with installed docs.
thread = {"configurable": {"thread_id": "recovery-case-17"}}
compiled.update_state(
    config=thread,
    values={"operation_id": "op-17", "approval": "granted"},
    as_node="approval_node",
)
result = compiled.invoke(None, config=thread)
assert result["operation_id"] == "op-17"

12. What invariants would you assert after every checkpointed node?

Assert required fields and schema, monotonic workflow phase, valid ownership, stable operation IDs, bounded retry count, legal next-node choices, and consistency between status and stored results. Domain-specific invariants matter more than serializability. Run them during tests and consider lightweight runtime guards before side effects. Strong invariants may reject legacy snapshots during deployment, so schema migration and compatibility policy must accompany them.

13. How would you test time-travel or forked-state debugging safely?

Copy the historical snapshot into a non-production thread and disable or fake side-effecting tools. Record the source checkpoint and modifications, then run the alternate path for diagnosis. Never mutate the authoritative customer history or let a debug fork use production operation identities. Forking improves root-cause analysis, but without isolation it can repeat real actions or make audit history ambiguous.

Protect Concurrency and Isolation

14. How would you handle two resume requests for the same thread?

Use per-thread concurrency control or optimistic checkpoint version checks so only one transition commits from a given snapshot. Tests release two workers at a barrier and assert one logical node execution or a safe conflict response. Side effects still need idempotency because locking can fail across process boundaries. Serializing every thread protects state but may reduce throughput; the design should serialize conflicting transitions, not unrelated conversations.

15. What test reveals state leakage between threads?

Run two threads with unique canary values, interleave their checkpoints and resumes, then inspect every snapshot and output for foreign fields. Repeat with reused workers, subgraphs, failures, and shared-store reads. The negative assertion is essential: each checkpoint history contains only its authorized values. A functional final answer may not reveal leaked context, while the privacy impact can be severe even if routing still succeeds.

16. How would you authorize a human operator who resumes a failed thread?

Require a role and case-specific permission, show a minimized snapshot, log reads and proposed state changes, and use a two-person approval for high-impact operations when risk warrants it. Resume under a service identity linked to the operator action. Tests cover unauthorized lookup, stale approval, and attempted field changes outside the allowed patch. Human-in-the-loop recovery expands capability and therefore needs a narrower, more observable trust boundary.

Evolve and Operate Persistence

17. How would you deploy a graph state schema change with active checkpoints?

Inventory persisted schema versions and choose backward-compatible reads, an explicit migration, or controlled retirement. Test old snapshots through the new graph in a copy, including pending nodes and side-effect IDs. Write new checkpoints with a schema marker and preserve migration provenance. Deploying code that only understands fresh state can strand long-running threads. Compatibility adds code, but silent coercion can route old state incorrectly.

18. What persistence health signals would you monitor?

Monitor checkpoint write and read errors, conflict rates, resume age, serialization failures, storage growth, orphaned pending threads, and recovery outcomes by node. Correlate with external operation reconciliation. Set retention from product and privacy requirements, not convenience. The persistence guide notes that unbounded checkpoint history can increase storage and latency, so pruning must preserve active recovery and audit obligations rather than deleting by age alone.

Score Recovery Judgment

19. How would you score a candidate who says to retry the failed node three times?

Ask what happened outside the graph, how attempts share an operation identity, which errors are retryable, and what checkpoint proves the next action. A fixed retry count without those answers is below senior level. Retries are appropriate for known transient failures at safe boundaries, with backoff and evidence. They are dangerous after ambiguous commits or deterministic validation failures. The number is secondary to the state and effect model.

20. What would a complete recovery test report contain?

Include graph and schema revision, thread and checkpoint references, injected fault location, pre-failure state, external effect ledger, chosen recovery action, resumed transitions, final state, output, and invariant results. Redact sensitive fields and retain restricted links where needed. The report should allow another engineer to explain why no work was lost or duplicated. "Resume passed" is a test outcome, not sufficient recovery evidence.

Resume Only From Proven Ground

Checkpointing creates the opportunity to recover; application design determines whether recovery is correct. Thread identity, state invariants, concurrency control, external idempotency, and migration policy must align before a failed workflow can continue safely.

The decisive senior response is to pause automatic resume whenever external truth and checkpoint truth disagree. Reconcile the operation, repair state through an audited path, and then verify one legal transition to completion. Availability matters, but resuming quickly from an untrusted boundary is simply a faster way to repeat damage.