mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-10-17 13:45:30 +02:00
3a1796ecf0
Depends on #8544 Resuming an exit-durability run after a parallel interrupt replays the resumed checkpoint's `DeltaChannel` writes wrong: twice on `main`, out of order if the duplicate is simply dropped. `p` finished before `q` interrupted, and `r` runs after `q`: ``` live: ['in1', 'p', 'r'] main, reload: ['in1', 'p', 'r', 'p'] ``` No fork is involved. Any exit-mode run that starts from a checkpoint with pending delta writes hits it: resuming an interrupt, or retrying after a task error. ## Cause Exit durability stores a run's delta writes on the checkpoint it started from, under step-prefixed task ids (`exit_delta_task_id`), so they replay in superstep order. On a resume, that checkpoint already holds the finished tasks' writes under their real task ids. The accumulator stored those loaded writes again under a step-prefixed id, so they replayed twice. Skipping them alone reorders the replay, because the real ids sort after the step-prefixed ones. ## Fix At exit: - writes loaded with the checkpoint are skipped, since they are already stored on it: `NULL_TASK_ID` writes by task id (this run's own `Command` writes are recorded separately in `_first`), the rest by `(task_id, channel)`; - the checkpoint's own superstep keeps its real task paths, so it interleaves with the loaded writes as live execution did, but gets a step-prefixed task id. Under the real id, a resume whose final checkpoint fails to save would leave the resumed task looking done, and the retry would skip it and lose its other writes; - a resume addressed by `checkpoint_id` reruns tasks whose writes are already stored on the checkpoint; their writes to those channels are skipped, and a write to a channel the task did not write before is kept; - later supersteps get task id `ffffffff-<step>-...` and task path `~~<step>...`, which sort after every real task id and every real task path, in step order. So superstep order holds whether a saver orders by task path (#8544) or only by task id. ## Limits - Within the resumed superstep, a saver that orders only by task id replays this run's writes before the ones loaded from the checkpoint. #8544 fixes that for the OSS savers. - If the final checkpoint fails to save, the writes of supersteps after the resumed one stay on the checkpoint and replay once more after the retry (on `main`, every write does). That comes from exit durability storing its writes before its checkpoint, not from this change. ## Tests `test_delta_channel_exit_mode.py`, on the shared checkpointer fixture (memory, sqlite, postgres) in all three durabilities: - resume after a parallel interrupt with a later write, plain and with the head's `checkpoint_id` - the resumed superstep interleaved by task path: `a_asks` resumes after `z_done` finished, and live order puts `a` first - the same runs on a saver that orders writes by task id only - a resume retried after its final checkpoint failed to save - a resume with `Command(resume=..., update=...)` that writes the delta channel replays that write once, in live order - an addressed resume whose rerun task writes a delta channel it did not write before keeps that write The exit cases fail without the change, except the last one, which guards against skipping by task id alone (an earlier version of this PR did); sync and async pass either way. #8548 marked exit durability in `test_resume_on_an_interrupted_head_consumes_its_writes_without_a_snapshot` as a strict expected failure for this bug; this PR drops the mark. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: ErenAta16 <149434812+ErenAta16@users.noreply.github.com> Co-authored-by: ragnarok268 <58264829+ragnarok268@users.noreply.github.com>