mirror of
https://github.com/langchain-ai/langgraph.git
synced 2026-10-14 12:15:25 +02:00
2b93e8b79f
Fixes langchain-ai/langgraph#8382 `DeltaChannel` rebuilds its value by replaying ancestor writes through the reducer. Every saver ordered a checkpoint's writes by `(task_id, idx)`, but live execution applies a super-step's writes in task-path order (`apply_writes` sorts tasks by `task_path_str(task.path[:3])`). `task_id` is a hash of the path, so when two or more tasks write one `DeltaChannel` in the same super-step, replay applies them in an arbitrary permutation. Reducers must be batching-invariant, not order-invariant, so the permutation changes the value: `get_state` disagrees with what `invoke` returned, and continuing the thread saves the reordered value as the base for every later write. ## Fix Replay orders by `(task_path, task_id, idx)`, the order `SELECT_PENDING_SENDS_SQL` already uses for sends. `apply_writes` and every saver now sort with one `writes_sort_key` from `langgraph.checkpoint.base`, in Python, so live and replay can't drift apart and don't depend on a database collation. `apply_writes` sorts by the full task path, the string `put_writes` stores, instead of `path[:3]`. The paths that reach `apply_writes` no longer carry task ids, so the live order doesn't change. `BaseCheckpointSaver`'s default `get_delta_channel_history` can't sort by path, since `PendingWrite` has no task path, so it replays each checkpoint's writes in `get_tuple` order. `get_tuple` now has to return `pending_writes` in `writes_sort_key` order, and memory, SQLite and Postgres do, so the default walk is right for any saver that follows that. `AsyncPostgresSaver` also gets the sync `get_delta_channel_history` that `AsyncSqliteSaver` already had; sync reads used to fall back to the default walk. Memory and Postgres already stored `task_path`. SQLite accepted it on `put_writes` and dropped it, so `writes` gains the column and `setup()` adds it to existing databases. Writes without a task path (graph input, `update_state` updates, rows written before the column existed) sort first by `task_id`, which is also where live execution applies input. ## Compatibility - Memory and Postgres already had `task_path` on disk, so existing threads replay in the corrected order after upgrade. - On SQLite, rows from before the upgrade read back as `''` and keep their old order. Only new writes get the corrected order, since there is no stored path to recover. - SQLite has no `ADD COLUMN IF NOT EXISTS`, so `setup()` runs the `ALTER` and treats `duplicate column name` as success, which also covers two processes migrating one file. That error comes while SQLite prepares the statement, before it asks for the write lock, so `setup()` on an up-to-date database doesn't wait on other writers. A read-only database from before the column is read with empty paths instead of failing setup. - Downgrade is safe: older code's `INSERT` omits the column and the column has a default. - `get_tuple` and `list` return `pending_writes` in `writes_sort_key` order instead of task id order (SQLite, Postgres) or put order (memory). Nothing in langgraph depends on the old order. - Postgres reads `task_path` and `idx` with each pending write, so a subclass that pairs `SELECT_SQL` with its own `_load_writes`, or the other way round, has to match the new row shape. - A third-party saver has to replay in `writes_sort_key` order: in its own `get_delta_channel_history` if it has one, otherwise by returning `pending_writes` from `get_tuple` in that order. Otherwise it fails the new conformance tests; the `get_tuple` one is a base test, so it runs for every saver. - langgraph, checkpoint-sqlite and checkpoint-postgres import `writes_sort_key` from langgraph-checkpoint, so this bumps langgraph-checkpoint to 4.3.0 and requires it there. 4.3.0 has to be released first. ## Limits - Several updates in one `bulk_update_state` super-step share a task id, so the saver keeps only the first one's writes and the `DeltaChannel` loses the rest (plain channels are fine). That's on main too; #9128 fixes it and stores a task path per update, so with this PR those updates also replay in the order given. - Exit durability stores its writes differently; resume ordering there is fixed in #9114, stacked on this PR. - langgraphjs applies `DeltaChannel` writes in task id order, live and on replay (langchain-ai/langgraphjs#2544), so its reads match too. Moving JS to task path order is a follow-up. ## Tests Each fails on main and passes here: - `test_delta_channel_parallel_order.py`, across memory, SQLite and Postgres: parallel writers and a `Send` fan-out, comparing `get_state` with the live result, including sync `get_state` on the async savers. - Three conformance tests whose task ids sort opposite to their task paths, so they cannot pass by chance: two on `get_delta_channel_history`, one on `get_tuple`'s `pending_writes` order. - SQLite migration tests from a pre-column database, sync and async, including a read-only file. One more that passes on main too: SQLite `setup()` while another connection holds the write lock, with no busy timeout, sync and async. It keeps the `ALTER` from waiting on that lock. Thanks to @ErenAta16 for the report, the reproduction, and for tracing `task_path` through all three backends, and to @ragnarok268 for the conformance-test design with task ids ordered opposite to their paths. --------- Co-authored-by: ErenAta16 <149434812+ErenAta16@users.noreply.github.com> Co-authored-by: ragnarok268 <58264829+ragnarok268@users.noreply.github.com>
46 lines
2.3 KiB
Docker
46 lines
2.3 KiB
Docker
# Thin layer on top of the latest published langgraph-api image.
|
|
#
|
|
# The base image bundles `langgraph_api`, `langgraph_runtime_postgres`,
|
|
# `langgraph_license`, `langgraph_grpc_common`, the Go `core-api-grpc`
|
|
# binary, and an entrypoint that starts both the gRPC server and uvicorn
|
|
# (`/storage/entrypoint.sh`). It also ships langgraph + langchain-core.
|
|
#
|
|
# We track the `latest-py3.12` tag rather than pinning a specific revision
|
|
# so CI surfaces upstream regressions early. If the base shifts under us,
|
|
# `docker compose build` will pick up the new digest on the next run.
|
|
#
|
|
# The image is the `licensed` variant, so it requires either a real
|
|
# `LANGSMITH_API_KEY` or a `LANGGRAPH_CLOUD_LICENSE_KEY` at runtime
|
|
# (passed through from the host shell / CI secrets, see docker-compose.yml).
|
|
|
|
FROM langchain/langgraph-api:latest-py3.12
|
|
|
|
# Graph dependencies not in the base image. `deepagents` is required for
|
|
# the deep_agent graph; the supervisor and researcher use a fake chat
|
|
# model (no `langchain-anthropic`) so no LLM API key is needed.
|
|
RUN pip install --no-cache-dir \
|
|
"langchain>=1.3.0" \
|
|
"deepagents>=0.6.2"
|
|
|
|
# Swap the published langgraph *core* and *checkpoint* for this monorepo's
|
|
# local copies, so the server executes the langgraph under test rather than the
|
|
# latest release.
|
|
# We keep the rest of the base image (langgraph-api, runtime, Go core server)
|
|
# on `latest` — that still surfaces upstream regressions — but the core the
|
|
# server runs is now the PR's, which is what lets this suite catch core
|
|
# regressions (e.g. ensure_config / runtime changes) before they're published.
|
|
# Checkpoint goes with core because core can need a checkpoint API from the
|
|
# same release. `--no-deps` keeps the base image's already-compatible
|
|
# prebuilt/sdk. The local sources come from the `checkpoint_src` and
|
|
# `langgraph_src` additional build contexts (see docker-compose.yml).
|
|
COPY --from=checkpoint_src pyproject.toml README.md LICENSE /opt/checkpoint-src/
|
|
COPY --from=checkpoint_src langgraph /opt/checkpoint-src/langgraph/
|
|
COPY --from=langgraph_src pyproject.toml README.md LICENSE /opt/langgraph-src/
|
|
COPY --from=langgraph_src langgraph /opt/langgraph-src/langgraph/
|
|
RUN pip install --no-cache-dir --force-reinstall --no-deps \
|
|
/opt/checkpoint-src /opt/langgraph-src
|
|
|
|
# Project graphs + registration config.
|
|
COPY graph/ /app/graph/
|
|
COPY langgraph.json /app/langgraph.json
|