Checkpointer startup and shutdown ordering
Agent server v0.4.5 ensures the checkpointer starts and stops correctly before and after the queue to improve shutdown and startup efficiency in deployments.
LangChain · LangGraph · all subjects
persistence & checkpointing
19 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Thread_id and checkpoint retrieval with persistence
Agent server v0.5.1 resolved an issue where persistence was not functioning correctly with LangChain.js's createAgent feature, ensuring that persisted data can be retrieved using thread_id and checkpointer.
langgraph-checkpoint version requirement for v0.5.0
Agent server v0.5.0 requires langgraph-checkpoint versions later than 3.0 to prevent a deserialization vulnerability in earlier versions. The langgraph-checkpoint library is compatible with langgraph minor versions 0.4, 0.5, 0.6, and 1.0.
JSON deserialization configuration for persisted payloads
Agent server v0.5.0 removes default support for deserialization of payloads saved using the 'json' type. To deserialize payloads containing custom Python objects that were saved in older 'json' mode, provide a serde config with allowed_json_modules listing the module paths and type names. Configuration example: checkpointer.serde.allowed_json_modules with array values like ['my_agent', 'my_file', 'SomeType'].
Durability modes for checkpoint optimization
Minimize redundant checkpointing by setting durability to the minimum value necessary to ensure data is durable. The default durability mode is 'async', meaning checkpoints are written after each step asynchronously. If an assistant needs to persist only the final state of the run, durability can be set to 'exit', storing only the final state of the run. This can be set when creating the run using the durability parameter.
Agent Server persistence types and backends
Agent Server persists three types of data, all backed by PostgreSQL by default: (1) Core resource data (assistants, threads, runs, cron jobs) always stored in PostgreSQL; (2) Checkpoints (short-term memory) - snapshots of graph execution state written at each step. Durability mode controls checkpoint frequency: 'async' (default) writes after each step, 'exit' stores only final state. Can switch to MongoDB or custom implementation; (3) Store (long-term memory) - persists across threads enabling agents to retain information between conversations. Stored in PostgreSQL by default but can be replaced with custom implementation.
Thread ID required for checkpointing
When invoking a graph compiled with a checkpointer, pass a thread_id in the configurable parameters to enable state persistence: {"configurable": {"thread_id": "1"}}. The same thread_id will retrieve the previous state on subsequent invocations.
Example: Postgres checkpointer with MessagesState
Example showing sync usage of PostgresSaver checkpointer with MessagesState. Creates a simple graph with one node that calls a model, compiles with PostgresSaver, and uses stream_events with thread_id to persist conversation state across multiple invocations.
Example: Async Postgres checkpointer
Example showing async usage of AsyncPostgresSaver with async nodes and astream_events. Demonstrates how to handle async persistence with database-backed checkpointing.
Example: MongoDB checkpointer
Example showing MongoDBSaver usage for checkpointing. Requires MongoDB cluster setup. Demonstrates both sync and async patterns for persisting graph state.
Example: Redis checkpointer
Example showing RedisSaver usage for checkpointing. Demonstrates sync and async patterns for persisting graph state via Redis.
Example: Oracle checkpointer
Example showing OracleSaver usage for checkpointing. Requires Oracle AI Database instance. Demonstrates both sync and async patterns for persisting graph state.
View thread state and checkpoint history
Call graph.get_state(config) to retrieve the current state of a thread specified by configurable thread_id. Optionally provide checkpoint_id to view a specific historical checkpoint; otherwise the latest is shown. Call graph.get_state_history(config) to list all checkpoints for a thread, returned in reverse chronological order with StateSnapshot objects containing values, config, metadata, and parent_config.
Delete all checkpoints for a thread
Call checkpointer.delete_thread(thread_id) to permanently delete all checkpoints associated with a specific thread, effectively clearing all saved state history for that thread.
InMemorySaver checkpointer for development
InMemorySaver is a checkpointer for in-memory persistence suitable for development. Import from langgraph.checkpoint.memory and pass it to builder.compile(checkpointer=checkpointer).
PostgresSaver checkpointer for production
PostgresSaver is a production-grade checkpointer backed by PostgreSQL. Create it via PostgresSaver.from_conn_string(DB_URI) and pass to builder.compile(checkpointer=checkpointer). Call checkpointer.setup() once before first use.
MongoDBSaver checkpointer for production
MongoDBSaver is a production-grade checkpointer backed by MongoDB. Create it with MongoDBSaver.from_conn_string(MONGODB_URI) or new MongoDBSaver({ client }) and pass to builder.compile(checkpointer=checkpointer). Requires a MongoDB cluster.
RedisSaver checkpointer for production
RedisSaver is a production-grade checkpointer backed by Redis. Create it via RedisSaver.from_conn_string(DB_URI) and pass to builder.compile(checkpointer=checkpointer). Call checkpointer.setup() once before first use.
OracleSaver checkpointer for production
OracleSaver is a production-grade checkpointer backed by Oracle AI Database. Create it via OracleSaver.from_conn_string(DB_URI) and pass to builder.compile(checkpointer=checkpointer). Call checkpointer.setup() once before first use. Requires an Oracle AI Database instance.