base

Protocol for serialization and deserialization of objects.

• dumps_typed: Serialize an object to a tuple (type, bytes).
• loads_typed: Deserialize an object from a tuple (type, bytes).

Valid implementations include the pickle, json and orjson modules.

Serializer that encrypts and decrypts data using an encryption protocol.

Serializer that uses ormsgpack, with optional fallbacks.

Metadata associated with a checkpoint.

State snapshot at a given point in time.

A tuple containing a checkpoint and its associated data.

Per-channel result entry from BaseCheckpointSaver.get_delta_channel_history.

Storage-level view of what one channel contributed across the ancestor chain of a target checkpoint:

• writes — on-path deltas oldest→newest as PendingWrite tuples. Always present; possibly empty. Already filtered to one channel. Writes stored at the target checkpoint itself are pending for the next super-step and are excluded.

  Within a single checkpoint, writes are ordered by writes_sort_key, (task_path, task_id, idx), which is the order live execution applies a super-step's task writes in. task_id is a hash of the path, so ordering by it permutes parallel tasks writing one channel, and reducers need not be order-invariant. Writes stored without a task_path (graph input, update_state and Command updates, rows predating the column) sort first, by task_id.

• seed — the stored value at the nearest ancestor whose channel_values[ch] is populated. Omitted if the walk reached the root without finding any stored value (consumer treats absence as "start empty"). Typically a _DeltaSnapshot for delta channels with finite snapshot frequency, or a plain value for threads migrated from a pre-delta channel type.

Base class for creating a graph checkpointer.

Checkpointers allow LangGraph agents to persist their state within and across multiple interactions.

When a checkpointer is configured, you should pass a thread_id in the config when invoking the graph:

config = {"configurable": {"thread_id": "my-thread"}}
graph.invoke(inputs, config)

The thread_id is the primary key used to store and retrieve checkpoints. Without it, the checkpointer cannot save state, resume from interrupts, or enable time-travel debugging.

How you choose thread_id depends on your use case:

• Single-shot workflows: Use a unique ID (e.g., uuid4) for each run when executions are independent.
• Conversational memory: Reuse the same thread_id across invocations to accumulate state (e.g., chat history) within a conversation.

Raised when attempting to get the value of a channel that hasn't been updated for the first time yet.