LangGraph 1.2.16 Separates Resume From Replay

LangGraph 1.2.16 is a patch release whose most consequential changes are about a hard property: resuming an interrupted graph should not repeat work that has already happened.

That sounds obvious. In an agent runtime, it is not. A graph can pause several parallel tasks for human decisions, persist writes under different durability modes, and later resume one answer at a time. If replay bookkeeping is wrong, the final state may look correct while an external side effect—sending mail, charging an account, or writing to an API—runs twice.

Four resume paths were tightened

The release incorporates four related fixes in the Python runtime.

First, an invalid answer in a multi-answer resume no longer cancels the other answered tasks immediately. The reported failure mode was operationally serious: one task could perform its side effect, be cut off while awaiting a response, retain its saved answer, and then run again after the invalid sibling answer was corrected. The fix lets those other tasks finish and saves their results before raising the validation error.

Second, a Command(resume=..., update=...) update is now applied once when a node interrupts again. The defect came from write positions changing as a resume write entered and later left the null task’s write list; the same regular update could therefore be persisted under two indexes.

Third, completed tasks in a subgraph no longer rerun on an ordinary resume. The runtime had treated the presence of a checkpoint_id key—even a null one—as replay. The new logic distinguishes a plain resume at the current head from time travel to an older checkpoint. That distinction matters because replay is expected to rerun work; resume is expected to continue it.

Fourth, durability="exit" now saves only writes produced during the resumed run. Previously, loading and then saving all pending writes could re-index an earlier task’s output, causing it to be applied twice when three or more parallel interrupts were answered sequentially.

These are not four cosmetic edge cases. Together they clarify an execution invariant: persisted answers and completed task writes should survive continuation without turning continuation into replay.

Direct verification

I checked out release tag 1.2.16 at commit 41c9c22fdc83d68a2859d0c9a2b627c8615a792f and ran the three focused regression tests named by the fixes:

• test_invalid_resume_lets_other_answered_tasks_finish
• test_resume_with_update_applies_the_update_once
• test_finished_task_output_applies_once

On Python 3.11.15 under Windows, the suite expanded to 20 cases across the in-memory and SQLite checkpointers, including encrypted SQLite where applicable, and the sync, async, and exit durability modes. Result: 20 passed in 0.77 seconds.

I set NO_DOCKER=true, so this result does not cover Redis or PostgreSQL. It also does not reproduce the whole LangGraph suite or any real external side effect. What it directly verifies is that the release-tag code passes the targeted continuation regressions against its local checkpointer matrix.

PostgreSQL gets explicit retention, with boundaries

The same release line includes langgraph-checkpoint-postgres 3.2.0, adding prune and aprune to the synchronous and asynchronous PostgreSQL savers. Two strategies are documented in the merged change: delete removes a thread’s checkpoints, writes, and blobs; keep_latest retains the newest checkpoint per namespace, its pending writes, and referenced blobs.

The design is deliberately conservative. keep_latest refuses threads detected as using DeltaChannel, because reconstructing the latest delta value can depend on older checkpoints. The change also documents that concurrent prunes can produce serialization failures or deadlocks, that replaying from a checkpoint while it is being pruned is unsafe, and that reclaiming table-file space still requires PostgreSQL maintenance such as VACUUM FULL or pg_repack.

I inspected this implementation and its published test plan but did not run its PostgreSQL tests locally. The pull request reports 71 saver tests and 39 graph tests on PostgreSQL 15 and 16; those counts are upstream claims, not my observed result.

Field note

For dependable agents, “human in the loop” is only as safe as the boundary between interruption, persistence, and replay. An approval prompt can prevent an action from starting too early, but it cannot make the action exactly-once if the runtime later confuses continuation with re-execution.

LangGraph 1.2.16 improves that boundary, but it does not create transactional exactly-once delivery for arbitrary APIs. Operators should still give side-effecting tools idempotency keys, persist operation identifiers, and test crash and resume paths against the actual checkpointer and durability mode they deploy. The runtime should avoid duplicate execution; the tool boundary should make a duplicate harmless if one still occurs.