mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-10-17 13:45:30 +02:00
456e2b1acc
Fixes #8551 `update_state` stores its writes on the checkpoint it addresses. A `DeltaChannel` rebuilds its value by replaying the writes stored on its ancestors, so when that checkpoint already has another child, the edit shows up in that branch too. #8551's repro, editing an earlier turn and then reading the branch that already existed: ``` before the edit: ['in-1', 'first-out', 'in-2', 'second-out'] after the edit: ['in-1', 'first-out', 'patched', 'in-2', 'second-out'] ``` The plain reducer channel in the same graph is unaffected. #8548 already keeps the edited branch itself correct; this is the other direction. ## Fix When `update_state` addresses a checkpoint that is not the thread's latest, the checkpoint it creates snapshots the delta channels the update writes, through the same snapshot #8548 adds for forks, and none of the update's writes are stored on the addressed checkpoint, whatever channels it writes. The edited branch reads the snapshot, and the other branches have nothing new to replay. The addressed checkpoint stays as it was, so a later `as_node=END` update on it doesn't take the edit in, and the edit doesn't show as that checkpoint's task result. On `main` both can happen in any graph, with or without a `DeltaChannel`, and a `DeltaChannel` also takes in the other branch's writes. "Not the latest" is one extra `get_tuple` for the thread, made when the config names a `checkpoint_id`. It compares with the latest put, so a checkpoint that has a child always counts. So does a leaf of an abandoned branch, such as the old head after a fork elsewhere, where nothing could leak; telling the two apart would mean listing the thread, since savers have no lookup by parent. The addressed checkpoint's pending writes can't answer it either: a finished turn that a later run continued from has none, which is #8551's case. Updates on the latest checkpoint are unchanged: no snapshot, same writes. ## Cost Editing an older checkpoint stores one snapshot per delta channel the update writes, the size of that channel's regular snapshot. That includes editing a leaf of an abandoned branch, as above. ## Limits - Threads that already leaked keep the leaked write, since it is stored on the old checkpoint. - The second report in #8551, `RemoveMessage(id=REMOVE_ALL_MESSAGES)` through `_messages_delta_reducer`, is that reducer's documented limit and isn't changed here. ## Tests `test_delta_channel_fork.py`, on the shared checkpointer fixtures: - `update_state` / `aupdate_state` on an older checkpoint, both a finished turn and one whose next node already ran there: the other branch reads back unchanged, and continuing it stays clean - `bulk_update_state` with two supersteps from an older checkpoint - `update_state` with the head's `checkpoint_id` still stores no snapshot - `update_state(None, as_node=END)` on an edited checkpoint: an older one leaves the edit out, also when it wrote only plain channels, and the latest one keeps it in both channels 33 of the 59 cases fail on `main`. The rest pass either way: the head case, the case whose next node already ran, where the saver keeps that node's own write and drops the edit's, and `as_node=END` on the latest checkpoint. Thanks to @AnnaSuSu for the report, the repro, tracing the leak to the writes landing on the addressed checkpoint, and the note that the fix needs a snapshot on the new checkpoint first. --------- Co-authored-by: Wenchao An <64579968+AnnaSuSu@users.noreply.github.com>