From 917ef684fa73e6ded914b974b8c6eb00d044ad12 Mon Sep 17 00:00:00 2001 From: Elior Nataf Lackritz Date: Tue, 29 Sep 2026 09:29:45 -0400 Subject: [PATCH] docs(checkpoint-sqlite): state the id ordering contract correctly in the walk comment Checkpoint ids are documented as monotonic; the guarantee only holds within one process, which is why the walk follows parent pointers. --- .../langgraph/checkpoint/sqlite/_delta.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/_delta.py b/libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/_delta.py index 21251c0e0..2f8c6e928 100644 --- a/libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/_delta.py +++ b/libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/_delta.py @@ -27,10 +27,10 @@ from typing import Any from langgraph.checkpoint.base import DeltaChannelHistory, PendingWrite # Stage 1 streams target, then its ancestors nearest-first, by following -# `parent_checkpoint_id`. Ids carry no ordering guarantee, so a range scan by -# id can miss a parent whose id sorts above its child's. Target is the anchor -# row; its own writes/seed are skipped (matches the `BaseCheckpointSaver` -# contract). +# `parent_checkpoint_id` rather than id order: ids are only monotonic within +# one process, so a range scan by id can miss a parent whose id sorts above +# its child's. Target is the anchor row; its own writes/seed are skipped +# (matches the `BaseCheckpointSaver` contract). # # `put` is `INSERT OR REPLACE`, so re-putting an existing id under a # descendant's config makes the chain a loop. `step_walk_with_row` stops on a