Files
langgraph/libs/checkpoint
3a1796ecf0 fix(langgraph): replay a resumed exit-mode run's delta writes in live order (#9114)
Depends on #8544

Resuming an exit-durability run after a parallel interrupt replays the
resumed checkpoint's `DeltaChannel` writes wrong: twice on `main`, out
of order if the duplicate is simply dropped. `p` finished before `q`
interrupted, and `r` runs after `q`:

```
live:            ['in1', 'p', 'r']
main, reload:    ['in1', 'p', 'r', 'p']
```

No fork is involved. Any exit-mode run that starts from a checkpoint
with pending delta writes hits it: resuming an interrupt, or retrying
after a task error.

## Cause

Exit durability stores a run's delta writes on the checkpoint it started
from, under step-prefixed task ids (`exit_delta_task_id`), so they
replay in superstep order. On a resume, that checkpoint already holds
the finished tasks' writes under their real task ids. The accumulator
stored those loaded writes again under a step-prefixed id, so they
replayed twice. Skipping them alone reorders the replay, because the
real ids sort after the step-prefixed ones.

## Fix

At exit:

- writes loaded with the checkpoint are skipped, since they are already
stored on it: `NULL_TASK_ID` writes by task id (this run's own `Command`
writes are recorded separately in `_first`), the rest by `(task_id,
channel)`;
- the checkpoint's own superstep keeps its real task paths, so it
interleaves with the loaded writes as live execution did, but gets a
step-prefixed task id. Under the real id, a resume whose final
checkpoint fails to save would leave the resumed task looking done, and
the retry would skip it and lose its other writes;
- a resume addressed by `checkpoint_id` reruns tasks whose writes are
already stored on the checkpoint; their writes to those channels are
skipped, and a write to a channel the task did not write before is kept;
- later supersteps get task id `ffffffff-<step>-...` and task path
`~~<step>...`, which sort after every real task id and every real task
path, in step order.

So superstep order holds whether a saver orders by task path (#8544) or
only by task id.

## Limits

- Within the resumed superstep, a saver that orders only by task id
replays this run's writes before the ones loaded from the checkpoint.
#8544 fixes that for the OSS savers.
- If the final checkpoint fails to save, the writes of supersteps after
the resumed one stay on the checkpoint and replay once more after the
retry (on `main`, every write does). That comes from exit durability
storing its writes before its checkpoint, not from this change.

## Tests

`test_delta_channel_exit_mode.py`, on the shared checkpointer fixture
(memory, sqlite, postgres) in all three durabilities:

- resume after a parallel interrupt with a later write, plain and with
the head's `checkpoint_id`
- the resumed superstep interleaved by task path: `a_asks` resumes after
`z_done` finished, and live order puts `a` first
- the same runs on a saver that orders writes by task id only
- a resume retried after its final checkpoint failed to save
- a resume with `Command(resume=..., update=...)` that writes the delta
channel replays that write once, in live order
- an addressed resume whose rerun task writes a delta channel it did not
write before keeps that write

The exit cases fail without the change, except the last one, which
guards against skipping by task id alone (an earlier version of this PR
did); sync and async pass either way.

#8548 marked exit durability in
`test_resume_on_an_interrupted_head_consumes_its_writes_without_a_snapshot`
as a strict expected failure for this bug; this PR drops the mark.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: ErenAta16 <149434812+ErenAta16@users.noreply.github.com>
Co-authored-by: ragnarok268 <58264829+ragnarok268@users.noreply.github.com>
2026-10-06 22:05:55 +00:00
..

LangGraph Checkpoint

PyPI - Version PyPI - License PyPI - Downloads Twitter

To help you ship LangGraph apps to production faster, check out LangSmith. LangSmith is a unified developer platform for building, testing, and monitoring LLM applications.

Quick Install

uv add langgraph-checkpoint

🤔 What is this?

This library defines the base interface for LangGraph checkpointers. Checkpointers provide a persistence layer for LangGraph: they save graph state at every superstep, enabling human-in-the-loop, memory between interactions, durable execution, and more.

📖 Documentation

For full documentation, see the API reference. For conceptual guides on persistence and memory, see the LangGraph Docs.

Key concepts

Checkpoint

Checkpoint is a snapshot of the graph state at a given point in time. Checkpoint tuple refers to an object containing checkpoint and the associated config, metadata and pending writes.

Thread

Threads enable the checkpointing of multiple different runs, making them essential for multi-tenant chat applications and other scenarios where maintaining separate states is necessary. A thread is a unique ID assigned to a series of checkpoints saved by a checkpointer. When using a checkpointer, you must specify a thread_id and optionally checkpoint_id when running the graph.

  • thread_id is simply the ID of a thread. This is always required.
  • checkpoint_id can optionally be passed. This identifier refers to a specific checkpoint within a thread. This can be used to kick off a run of a graph from some point halfway through a thread.

You must pass these when invoking the graph as part of the configurable part of the config, e.g.

{"configurable": {"thread_id": "1"}}  # valid config
{
    "configurable": {
        "thread_id": "1",
        "checkpoint_id": "0c62ca34-ac19-445d-bbb0-5b4984975b2a",
    }
}  # also valid config

Serde

langgraph-checkpoint also defines protocol for serialization/deserialization (serde) and provides a default implementation (langgraph.checkpoint.serde.jsonplus.JsonPlusSerializer) that handles a wide variety of types, including LangChain and LangGraph primitives, datetimes, enums and more.

Important

Checkpoint deserialization security: By default the serializer allows any Python type found in checkpoint data. New applications should set the environment variable LANGGRAPH_STRICT_MSGPACK=true or pass an explicit allowed_msgpack_modules list to JsonPlusSerializer to restrict deserialization to known-safe types.

Pending writes

When a graph node fails mid-execution at a given superstep, LangGraph stores pending checkpoint writes from any other nodes that completed successfully at that superstep, so that whenever we resume graph execution from that superstep we don't re-run the successful nodes.

Interface

Each checkpointer should conform to langgraph.checkpoint.base.BaseCheckpointSaver interface and must implement the following methods:

  • .put - Store a checkpoint with its configuration and metadata.
  • .put_writes - Store intermediate writes linked to a checkpoint (i.e. pending writes).
  • .get_tuple - Fetch a checkpoint tuple using for a given configuration (thread_id and checkpoint_id).
  • .list - List checkpoints that match a given configuration and filter criteria.
  • .delete_thread() - Delete all checkpoints and writes associated with a thread.
  • .get_next_version() - Generate the next version ID for a channel.

If the checkpointer will be used with asynchronous graph execution (i.e. executing the graph via .ainvoke, .astream, .abatch), checkpointer must implement asynchronous versions of the above methods (.aput, .aput_writes, .aget_tuple, .alist). Similarly, the checkpointer must implement .adelete_thread() if asynchronous thread cleanup is desired. The base class provides a default implementation of .get_next_version() that generates an integer sequence starting from 1, but this method should be overridden for custom versioning schemes.

Usage

from langgraph.checkpoint.memory import InMemorySaver

write_config = {"configurable": {"thread_id": "1", "checkpoint_ns": ""}}
read_config = {"configurable": {"thread_id": "1"}}

checkpointer = InMemorySaver()
checkpoint = {
    "v": 4,
    "ts": "2024-07-31T20:14:19.804150+00:00",
    "id": "1ef4f797-8335-6428-8001-8a1503f9b875",
    "channel_values": {"my_key": "meow", "node": "node"},
    "channel_versions": {"__start__": 2, "my_key": 3, "start:node": 3, "node": 3},
    "versions_seen": {
        "__input__": {},
        "__start__": {"__start__": 1},
        "node": {"start:node": 2},
    },
}

# store checkpoint
checkpointer.put(write_config, checkpoint, {}, {})

# load checkpoint
checkpointer.get(read_config)

# list checkpoints
list(checkpointer.list(read_config))

📕 Releases & Versioning

See our Releases and Versioning policies.

💁 Contributing

As an open-source project in a rapidly developing field, we are extremely open to contributions, whether it be in the form of a new feature, improved infrastructure, or better documentation.

For detailed information on how to contribute, see the Contributing Guide.