Files
langgraphjs/libs/checkpoint
John Kennedy 8fb6376a75 chore: update Vitest to 4.1.9 (#2587)
## Summary
- update all workspace `vitest` declarations to `4.1.9`
- update `@vitest/browser-playwright` and `@vitest/browser-webdriverio`
declarations to `4.1.9`
- refresh `pnpm-lock.yaml` so no `vitest`/`@vitest/browser` versions
below `4.1.9` remain

## Validation
- `sfw pnpm install`
- `pnpm format:check`
- `pnpm lint`
- `pnpm build`
- targeted audit check: no `vitest` or `@vitest/browser` advisories
remain
- `pnpm --filter create-langgraph test`
- `pnpm --filter @langchain/react test`
- `pnpm --filter @langchain/svelte test`
- `pnpm --filter @langchain/vue test`
- `pnpm --filter @langchain/angular test`
- `pnpm --filter @langchain/langgraph test`

## Notes
- `pnpm --filter @langchain/langgraph test:browser` did not run locally
because Playwright Chromium for the updated provider was not installed
on this machine; Vitest exited before running tests with Playwright's
`pnpm exec playwright install` message.
- The SDK Vitest suites passed but printed Vitest's post-success
close-timeout warning.

Co-authored-by: John Kennedy <jkennedyvz@users.noreply.github.com>
2026-07-03 23:18:35 -07:00
..
2026-06-24 17:51:02 -07:00
2025-07-02 02:35:57 +02:00

@langchain/langgraph-checkpoint

This library defines the base interface for LangGraph.js checkpointers. Checkpointers provide persistence layer for LangGraph. They allow you to interact with and manage the graph's state. When you use a graph with a checkpointer, the checkpointer saves a checkpoint of the graph state at every superstep, enabling several powerful capabilities like human-in-the-loop, "memory" between interactions and more.

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 of 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

@langchain/langgraph-checkpoint also defines protocol for serialization/deserialization (serde) and provides an default implementation that handles a range of 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.

When are checkpoints persisted

By default (durability: "async") checkpoint writes are dispatched in the background while the graph keeps executing, which keeps runs fast. Regardless of the durability mode, LangGraph awaits all outstanding checkpointer writes before invoke() / stream() resolves, invoke() fully drains the underlying stream, and the stream awaits every pending checkpointer promise before it completes.

In practice this means:

  • If you await graph.invoke(...) (or fully consume for await (... of graph.stream(...))), persistence is guaranteed to be complete by the time the call returns. You do not need to keep the process/runtime alive for any trailing background writes.
  • On serverless/edge runtimes (e.g. Cloudflare Workers) you therefore do not need ctx.waitUntil() to flush checkpoints, just make sure you await the run before returning a response. The only way to orphan writes is to start a stream and never consume it (e.g. piping graph.stream() into a detached, un-awaited task).

Note: this guarantees the write was issued and awaited, not that your database driver works in a given runtime. See the runtime-compatibility notes in the Postgres and Redis checkpointer READMEs.

Interface

Each checkpointer should conform to BaseCheckpointSaver interface and must implement the following methods:

  • .put - Store a checkpoint with its configuration and metadata.
  • .putWrites - Store intermediate writes linked to a checkpoint (i.e. pending writes).
  • .getTuple - Fetch a checkpoint tuple using for a given configuration (thread_id and thread_ts).
  • .list - List checkpoints that match a given configuration and filter criteria.

Usage

import { MemorySaver } from "@langchain/langgraph-checkpoint";

const writeConfig = {
  configurable: {
    thread_id: "1",
    checkpoint_ns: ""
  }
};
const readConfig = {
  configurable: {
    thread_id: "1"
  }
};

const checkpointer = new MemorySaver();
const checkpoint = {
  v: 1,
  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
    }
  },
  pending_sends: [],
}

// store checkpoint
await checkpointer.put(writeConfig, checkpoint, {}, {})

// load checkpoint
await checkpointer.get(readConfig)

// list checkpoints
for await (const checkpoint of checkpointer.list(readConfig)) {
  console.log(checkpoint);
}