checkpoint-sqlite: failed store batches can partially commit changes

[JunweiJia]

Checked for duplicates

I searched the open and closed issues for SQLite store batch rollback / partial commits and did not find an existing report.

Description

SqliteStore.batch() and AsyncSqliteStore.abatch() can partially persist changes when a later operation in the same batch raises.

Both SQLite store _cursor() context managers execute COMMIT in a finally block. As a result, they commit earlier mutations even when control exits the context because of an exception (or, for async code, cancellation).

One observable case is a TTL refresh performed by a GetOp before a later unserializable PutOp.

Reproduction

Sync:

from langgraph.store.base import GetOp, PutOp
from langgraph.store.sqlite import SqliteStore

original_expiration = "2000-01-01 00:00:00"

with SqliteStore.from_conn_string(
    ":memory:",
    ttl={"default_ttl": 10, "refresh_on_read": True},
) as store:
    store.setup()
    store.put(("test",), "key", {"value": "original"})
    store.conn.execute(
        "UPDATE store SET expires_at = ? WHERE prefix = ? AND key = ?",
        (original_expiration, "test", "key"),
    )

    try:
        store.batch([
            GetOp(("test",), "key", refresh_ttl=True),
            PutOp(("test",), "invalid", {"value": object()}),
        ])
    except TypeError:
        pass

    expires_at = store.conn.execute(
        "SELECT expires_at FROM store WHERE prefix = ? AND key = ?",
        ("test", "key"),
    ).fetchone()[0]

    assert expires_at == original_expiration  # currently fails

The equivalent async reproduction using AsyncSqliteStore.abatch() has the same result.

Actual behavior

The batch raises TypeError, but the TTL refresh from the preceding GetOp is committed. The database is left in a partially updated state.

Expected behavior

A failed batch should be atomic: any exception should roll back all changes made in that cursor context, and the original exception should be re-raised. The async path should also roll back on cancellation.

Root cause and proposed fix

The sync and async SQLite store _cursor() context managers unconditionally commit in finally:

• libs/checkpoint-sqlite/langgraph/store/sqlite/base.py
• libs/checkpoint-sqlite/langgraph/store/sqlite/aio.py

I propose changing both context managers to:

• COMMIT on normal exit;
• ROLLBACK on any BaseException, then re-raise;
• add sync and async regression tests demonstrating that an earlier TTL refresh is not persisted when a later operation fails.

I have a tested implementation ready. If this approach is acceptable, could a maintainer please assign this issue to me? I will then open the PR in accordance with the contribution policy.

[SnowingFox]

Opened a PR to address this: #8592

[SnowingFox]

Hi! I looked into this and have a fix prepared. Wanted to share the analysis so it's easy to evaluate.

Root cause: Both SQLite store _cursor() context managers execute COMMIT in a finally block:

• libs/checkpoint-sqlite/langgraph/store/sqlite/base.py:1053-1058 — finally: if transaction: self.conn.execute("COMMIT")
• async twin in libs/checkpoint-sqlite/langgraph/store/sqlite/aio.py:242-246

When a batch()/abatch() body raises mid-way (e.g. a PutOp whose value fails orjson.dumps with TypeError), the finally still commits earlier mutations — e.g. a TTL refresh (expires_at UPDATE) executed by a preceding GetOp(refresh_ttl=True). The DB is left partially updated instead of rolled back. The async path also fails to roll back on asyncio cancellation (CancelledError bypasses except Exception).

Fix: Make both context managers atomic — COMMIT only on normal exit (moved to the else clause), ROLLBACK + re-raise on any BaseException (covers cancellation too). Each batch()/abatch() becomes all-or-nothing.

Tests (TDD, verified RED on pristine + GREEN after):

• tests/test_store.py::test_batch_rollback_on_error — GetOp(refresh_ttl=True) + unserializable PutOp batch, asserts the earlier TTL refresh was NOT persisted
• tests/test_async_store.py::test_abatch_rollback_on_error — same for the async path

If this looks reasonable I'm happy to adjust. The PR is at #8592.

[lorenzozanee]

Hi, I'd like to pick this up — could you assign me? I have a fix in mind for the batch rollback.

[1320800521]

I independently reproduced this on Python 3.10.2 with langgraph-checkpoint-sqlite==3.1.1, using the synchronous SqliteStore.batch() path and an in-memory SQLite database (no model/API calls).

Minimal sequence:

store.batch([
    GetOp(("test",), "key", refresh_ttl=True),
    PutOp(("test",), "invalid", {"value": object()}),
])

Observed result:

langgraph-checkpoint-sqlite 3.1.1
caught TypeError
original_expiration 2000-01-01 00:00:00
actual_expiration 2026-08-12 03:26:59
partial_commit_reproduced True

So the later serialization TypeError does not roll back the earlier TTL refresh on this path. I only independently reran the synchronous path; I have not separately verified the async path yet.

Reproduction repo: https://github.com/xbstack/langgraph-sqlite-partial-commit-repro

Detailed write-up and production-boundary notes: https://www.xbstack.com/en/ai/langgraph-checkpointer-memory-sqlite-redis/?utm_source=github&utm_medium=referral&utm_campaign=langgraph_sqlite_partial_commit&utm_content=issue_comment

I will rerun the same fixture against the first candidate fixed release so the version matrix can show the exact rollback behavior change.

[jbdrak]

I opened draft PR #8601 with atomic sync/async SQLite batch transactions, rollback on exceptions and cancellation, and regression tests. The focused store suite and lint pass.

[jbdrak]

The first draft was auto-closed by the repository issue-link guard because external contributors must be assigned before opening an issue-linked PR. I reopened the same verified commit as draft PR #8605 from fix/sqlite-batch-rollback; no code changed.