NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.4 Manage stateful orchestration to coordinate complex tasks and knowledge retention.
Resume checkpoints without repeating external writes
Completed by the knowledge check
Learning objective
Persist checkpoints and resume interrupted workflows without duplicating side effects.
Core idea
A checkpoint records workflow progress. An external service records an action’s effect. Those records can disagree after a crash: the service might have accepted a write while the graph never saved its result. Restoring the checkpoint then exposes that action to another execution.
See 2.4.4 for action-level recovery and compensation, and 4.1.3 for background-job recovery. This lesson adds the graph-specific decision: where progress becomes durable, what resumes or replays, and how node placement changes the work repeated after interruption. A durable graph still needs replay-safe side effects.
How it works
Choose the checkpoint backend and write boundary
Use a persistent checkpointer and configurable.thread_id for restart recovery; see 1.8.3 for backend selection, asynchronous savers, and durability configuration. Here the question is which work a restored checkpoint exposes to execution again.
LangGraph checkpoints at super-step boundaries. Nodes scheduled in the same super-step can run in parallel. If one fails, successful nodes’ pending writes let recovery reuse their completed results instead of executing those nodes again. Those task writes are not additional full snapshots from which arbitrary time travel can begin. Keep the distinction between recovering successful work in an incomplete super-step and deliberately replaying from a previous checkpoint.
Read the durability modes from 1.8.3 in terms of their recovery exposure:
| Mode | What a process crash can leave unrecorded | Consequence for resumed work |
|---|---|---|
"sync" | The running step can perform an effect before its output is checkpointed | Reconcile that step’s external effect even though earlier checkpoints completed before execution continued |
"async" | A checkpoint write can still be pending while the next step executes | Include both the pending progress and subsequent work when investigating repeated execution |
"exit" | Intermediate progress since the previous saved state | Mid-run crash recovery is unavailable; restarting from saved state can repeat work and its side effects |
"sync" narrows uncertainty about graph progress. It does not make an external API call and a checkpoint write one transaction. If the process dies between those operations, action reconciliation still matters.
Resume the interrupted node deliberately
For a human pause, interrupt(payload) saves state through the checkpointer and returns the payload to the caller. Resume by invoking the graph with Command(resume=...) and the same thread_id. A different ID starts another thread rather than continuing the suspended one.
The interrupted node restarts from its beginning. Code before interrupt() executes again. Therefore, place the pause before a non-idempotent effect, or move the effect into a separate node after the approval node. Keep pre-interrupt work read-only or idempotent. The resume value becomes the return value of the matching interrupt() call; it is not a replacement for the entire graph state.
Inspect graph.get_state(config) when deciding what a suspended run awaits. Its tasks field includes interrupt and error information, while next identifies scheduled nodes. Validate the caller’s right to resume that task before supplying the response; see 1.4.2 for authenticated scopes. The saved cursor identifies the execution; application authorization decides who may operate it.
Design for the unrecorded-success window
The LangGraph interrupt documentation explicitly recommends idempotent operations, placing effects after interrupts, and separating effects into nodes. An upsert that assigns the same record state can be repeatable; creating another record on each call is not. “After approval” removes repetition caused by restarting the approval node, but a subsequent action node can still fail after the remote write succeeds.
Carry the stable action identity and provider result in execution state, using the action record from 2.4.4. On a replayable action node, reuse that identity and reconcile an uncertain result instead of generating another action identity. Where an integration cannot establish whether the first write happened and cannot safely repeat it, stop that action for reconciliation. Resuming the graph is not a reason to guess the external outcome.
Resuming restarts the interrupted approval node from its beginning, and an action node that fails after the remote write succeeds reuses its stable action identity to reconcile.
Deliberate time travel has a separate hazard. Invoking a prior checkpoint_id re-executes nodes after that checkpoint, including model calls and API requests. It is not a rollback of external systems. Use action deduplication for an operational replay, or isolate the replay from production mutations when its purpose is analysis.
Keep NVIDIA integration explicit
NeMo Agent Toolkit’s langgraph_wrapper loads the graph named by workflow.graph; see 1.8.3 for the integration requirements. NVIDIA notes that complex state management can require additional configuration or code changes. Configure checkpoint lifetime, thread association, and resume handling in the graph integration you deploy, then verify them through restart and interruption cases.
The YAML loader, the checkpoint backend, and the external tool adapter have distinct owners. The orchestration team owns persistence and recovery; the integration owner establishes whether repeated writes are safe. A successful nat invocation alone does not demonstrate crash recovery or deduplicated external actions.
Key distinctions and trade-offs
Resume versus replay: Resuming answers a pending interruption on its task thread. Replaying from an earlier checkpoint deliberately reruns downstream work. Both require careful side-effect placement, but they express different operational intent.
Pending writes versus remote writes: Pending writes preserve successful node outputs during super-step recovery. A remote system can accept an effect before any corresponding node output is saved.
Durability versus deduplication: A durable checkpoint reduces repeated computation. An idempotent action or reconciled action record prevents repeated business effects. Choose and verify both.
Architecture / decision scenario
A commercial insurance assistant prepares renewal documents, waits for underwriting approval, and then creates one policy endorsement. Preparation takes six minutes; approval can take two days. A duplicate endorsement requires manual correction and is unacceptable.
One proposal uses InMemorySaver and creates the endorsement immediately before interrupt() asks the underwriter to confirm. The workflow owner rejects both choices: deployment restarts would discard the suspended task, and resuming the approval would rerun the write that precedes it.
The team chooses a persistent checkpointer, durability="sync", and a stable task thread. An approval node pauses before mutation; a separate action node creates the endorsement using the action identity recorded for that task. If the service accepts the endorsement and the worker crashes before saving success, recovery reconciles that identity rather than creating another endorsement.
The platform team tests restart recovery at the two-day wait and at the write-to-checkpoint gap. The tool owner verifies the adapter’s deduplication or reconciliation behavior. Six minutes of recomputation might be tolerable; a second business write is not, so the faster "exit" mode and transcript-based reconstruction do not satisfy the recovery requirement.
Common exam traps
- Treating an in-memory saver as persistence across process restarts.
- Assuming execution resumes at the exact Python statement after an interruption.
- Placing record creation before
interrupt()and expecting approval to prevent duplication. - Assuming
durability="sync"atomically commits an external write. - Replaying an earlier checkpoint as though it undoes downstream business effects.
- Confusing saved pending node outputs with proof about an unrecorded remote action.
What to remember
Persist the graph, preserve its thread identity, and understand which node code runs again. Choose durability from the acceptable crash window. Put approval before mutation and retain replay-safe action identity, because checkpoint recovery and external-effect correctness are separate guarantees.
Knowledge check
A LangGraph node creates a policy endorsement and then calls interrupt() so that an underwriter can confirm it. The graph uses a persistent checkpointer, and the caller resumes with Command(resume=...) on the same thread_id. After each approval, the insurer finds two endorsements. Which change removes the cause of the duplicate?
thread_id instead of the old onedurability="sync" before the pauseinterrupt() runs again. Placing the non-idempotent effect in its own node after approval removes that repetition. A new thread_id starts another thread, "sync" concerns checkpoint timing, and the resume value only becomes the return value of interrupt() , after the creation has already rerun.A graph invoked with durability="sync" has an action node that submits a refund. The provider accepts the refund, and the worker crashes before the node’s output is saved. On recovery the action node runs again. An earlier node recorded its stable action identity in execution state, and the provider can look up a refund by that identity. How should the rerun proceed?
"sync" to have committed the refund"sync" writes each checkpoint before the next step starts, but it does not make an external call and a checkpoint write one transaction. Pending writes preserve outputs of nodes that completed, and this node never saved one. Reusing the recorded identity lets the node reconcile the uncertain result instead of creating a second refund.An approval service resumes interrupted workflows over HTTP, with a persistent PostgreSQL checkpointer. Each resume request generates a new UUID for configurable.thread_id. Instead of continuing, every approval starts a fresh run from the graph’s first node. What fixes it?
Command(resume=...) on the suspended task’s thread_iddurability="sync" when invoking the graph to resumeCommand(resume=...)graph.get_state(config) with the new UUID before resuminginterrupt() call rather than replacing the graph state, and reading state under the new ID finds nothing.An analyst wants to understand why a claim was misrouted by replaying a production run from a prior checkpoint_id. A node after that checkpoint sends the customer a new email each time it executes. The replay is for analysis only. How should the analyst run it?
References
- LangChain, Checkpointers
- LangChain, Persistence
- LangChain, Interrupts
- NVIDIA, Running Existing LangGraph Agents in NVIDIA NeMo Agent Toolkit