LangGraph SQLite checkpoints retain part of a failed write batch

An agent can raise an error and still leave some pending writes behind. A new LangGraph issue reports that SqliteSaver and AsyncSqliteSaver partially persist a failed or cancelled put_writes batch. In its injected-error test, the first of three new writes survived although the batch raised, creating a recovery state the caller did not expect.

Scope the affected path

Inventory where your graph uses SQLite checkpoint savers, pending writes and recovery after cancellation. The report names langgraph-checkpoint-sqlite 3.1.2 and 3.1.3 in specific tests; it is not evidence that every checkpointer has the same behavior.

Test the failure boundary

In an isolated database, seed a checkpoint, inject an error on a later write in a batch, and inspect pending writes from both the same and a fresh connection. Also test cancellation followed by another successful commit. Check whether the application retries or replays work under a partially written state.

Limit operational exposure

Until an upstream fix is available and verified, avoid treating a raised batch call as proof that no writes persisted. Make recovery idempotent and compare expected tool outputs with checkpoint state before resuming sensitive work. Do not patch database rows manually in production.

Adovo’s view

Agent memory is a transaction boundary. If the graph remembers half a failed step, its next decision can be coherent in code and wrong in reality. The operating standard is a recoverable state, verified under interruption.