fix: rebuild crashes with "cannot start a transaction within a transaction"

[realkotob]

The problem

Running code-review-graph build on a large repo (~9k files) after an earlier interrupted build crashes almost immediately with:

sqlite3.OperationalError: cannot start a transaction within a transaction

I hit this on a big source tree on my Macbook M1 Pro. The first build ran through the parse phase to completion, then I Ctrl-C'd it while community detection was stuck (separate perf issue — the file-based fallback is quadratic on large graphs). On the retry, the rebuild blew up on the very first file:

INFO: Progress: ... files parsed ... (never gets here)
Traceback (most recent call last):
  ...
  File ".../incremental.py", line 397, in full_build
      store.store_file_nodes_edges(...)
  File ".../graph.py", line 239, in store_file_nodes_edges
      self._conn.execute("BEGIN IMMEDIATE")
sqlite3.OperationalError: cannot start a transaction within a transaction

Why it happens

full_build starts by purging any files that used to exist in the DB but no longer exist on disk:

for stale in existing_files - current_abs:
    store.remove_file_data(stale)

remove_file_data issues two DELETE statements and returns without committing. Under Python's default (legacy) sqlite3 isolation mode, those DELETEs silently open an implicit transaction. The very next store_file_nodes_edges() call then runs an explicit BEGIN IMMEDIATE — and SQLite rejects it because one is already open.

The reason this went undetected is that the purge loop is usually a no-op: if every file still exists on disk, existing_files - current_abs is empty and the buggy path never runs. My interrupted build had left the DB with thousands of file rows whose absolute paths no longer matched the set the rebuild was computing, so every single one was treated as stale and the connection was left dirty before parsing even started.

The fix

Two parts:

1. incremental.py — full_build now calls store.commit() once after draining the purge loop, so the parse phase starts with a clean connection.
2. graph.py — store_file_nodes_edges checks conn.in_transaction and flushes any dangling implicit transaction before its BEGIN IMMEDIATE. Defensive: if any future code path leaves DML uncommitted, the atomic per-file replace still works instead of crashing the build.

Test plan

• New regression test test_store_file_nodes_edges_after_dangling_dml primes an implicit transaction via remove_file_data and asserts store_file_nodes_edges still succeeds. Fails on main, passes with the fix.
• uv run pytest tests/test_graph.py tests/test_incremental.py — 45 passed
• uv run pytest tests/test_tools.py tests/test_integration_v2.py — 66 passed
• Manually reproduced the crash on a real repo and confirmed the fix allows the rebuild to proceed past the purge loop.

[tirth8205]

This was closed in favor of #205 which was just merged and provides a more complete fix.

Your PR correctly identifies the two-part fix: commit after the stale-file purge loop in full_build(), and an in_transaction guard in store_file_nodes_edges(). Both of those changes are also present in #205.

However, PR #205 goes further:

1. Root cause elimination: sets isolation_level=None on all sqlite3.connect() calls in graph.py, registry.py, and embeddings.py — so implicit transactions can never leak again.
2. Incremental path too: adds the corresponding store.commit() after the deleted-file loop in incremental_update().
3. Atomicity: wraps store_flows(), store_communities(), and all three _compute_summaries blocks in explicit transactions.
4. More regression tests: 2 new tests covering both single and bulk remove-then-store scenarios.

Your root-cause analysis was excellent and helped clarify the problem for everyone. Thank you for the contribution.