mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-10-14 12:15:25 +02:00
Elior Nataf LackritzandGitHub
2d942085e2
Depends on #9165 A replay saves a fork checkpoint first, so its writes land on the fork. Two things still reached the checkpoint it replayed from, and through it every branch that already grew from that checkpoint. It skips the fork for an update or fork checkpoint, which is already a branch of its own. Once the thread has moved past such a checkpoint it can have children, and the replay's writes stored on it reach every one of them. Edit a checkpoint, continue from it, then replay the edit, and the branch you continued reads back a write it never ran: ``` plain channel: ['in1', 'a', 'b', 'edit', 'in2', 'a', 'b'] DeltaChannel: ['in1', 'a', 'b', 'edit', 'b', 'in2', 'a', 'b'] ^ the replay's b ``` And a `Command(update=...)` or `Command(goto=...)` replayed from any checkpoint stored its writes there before the run saved its fork. The branches that grew from that checkpoint replayed the update into a `DeltaChannel`, and a later replay of the same checkpoint repeated the old `Command`: the update again, in every channel, or the `goto`'s node again. Both happen on `main`. ## Fix Loading a checkpoint addressed by `checkpoint_id` checks, for update and fork checkpoints only, whether the thread has moved past it, with #9165's `checkpoint_superseded`. If it has, the replay saves its fork checkpoint as it does from any other checkpoint. Subgraphs keep replaying from the edit's parent, as they did without the fork. The run decides on the fork before it stores anything. When it forks, it keeps the `Command`'s writes in memory and applies them, and the fork snapshots the delta channels they write, so the fork carries them and nothing lands on the checkpoint the run addressed. Cost: one extra `get_tuple` when a run addresses an update or fork checkpoint by `checkpoint_id`, such as resuming with the config `update_state` returned. A replay from an edit the thread moved past stores one more checkpoint, and a forked `Command` that writes a delta channel stores a snapshot of it. ## Limits - A `Command(resume=...)` addressed at a checkpoint the thread moved past doesn't fork, so its run's writes still land there, and a branch that grew from that checkpoint without answering the interrupt replays them. Same on `main`. A fork would give the tasks new ids, and interrupt ids and resume-map keys are hashes of the task's namespace, which includes the task id, so a resume map built from the interrupts the caller just read would stop matching. This needs writes that record their branch (#9174). ## Tests `test_delta_channel_fork.py`, on the shared checkpointer fixtures in all durabilities: - replay from an edit the thread moved past, with and without a subgraph, sync and async, with no input and with `Command(update=...)` - a `Command(update=...)` or `Command(goto=...)` replay of a plain checkpoint the thread moved past: the branch that grew from it reads back unchanged, and a later replay of the checkpoint doesn't repeat the `Command` 124 of the 186 cases fail on #9165; the exit ones pass either way.