How do you resume an interrupted graph run from a checkpoint?

What you need to know

1config = {"configurable": {"thread_id": "research-2026-09-24-17"}}23state = graph.get_state(config)4print(state.next)            # ('synthesise',)  — where it stopped5print(state.interrupts)      # () if it crashed, payloads if it paused67if state.interrupts:8    graph.invoke(Command(resume={"approved": True}), config)9else:10    graph.invoke(None, config)       # continue after a crash

Three inputs, three meanings

Passing a dict when you meant to resume starts a new pass over the graph with the old state — a common bug.

What re-runs

• Nodes completed in earlier super-steps: not re-run; their writes are saved.
• Parallel siblings that finished in the failing super-step: not re-run; their pending writes are saved.
• The failed or interrupted node: re-runs from the top.

So: put side effects after interrupt() or in a separate node, and give external calls idempotency keys.

A real-life example

A research agent generates a 30-page sector report: 14 searches, 20 model calls, then a synthesis step. At minute 11, a deploy kills the pod during synthesise. The job runner sees the run failed, reads get_state(config).next == ("synthesise",) and calls graph.invoke(None, config) on a new pod. Only synthesis runs again — about Rs 6 of model calls — instead of all 34 calls costing Rs 55. The user sees a 40-second delay, not a failed report.

Follow-up questions to expect

• "How do you find runs to resume after a crash?" — Record run status in your job table; on startup, list threads whose last checkpoint has a non-empty next and no interrupt, and resume them.
• "Can you resume on a different machine?" — Yes, with a shared checkpointer such as Postgres. That is the point of durable execution.
• "Can you resume with changed input?" — Use update_state to change state first, or Command(resume=..., update=...) to answer and update in one call.