perf(code-graph): batch index inserts in one transaction (large-repo first index 86s → 5s)

[sshanzel]

What changed

insertMany (the core index insert path) prepared its statement once but awaited execute per row with no transaction, so Kùzu auto-committed (fsync'd) every row. A large first index was ~14k serial commit round-trips — most of a ~70s wait. Since the first review auto-indexes, a stranger's first run on a real repo blocked ~90s.

Wrap each batch's row loop in a single BEGIN TRANSACTION … COMMIT (ROLLBACK on error): one commit instead of thousands, and the batch is now atomic — a failure rolls back instead of leaving a half-written graph (safe now that symbol ids are collision-proof, so no mid-batch PK abort).

Measured (playright, 1328 files)

	Before	After
Full index wall-clock	86.2s	4.98s (~17×)
Graph produced	1328 files / 4759 symbols / 4255 imports	identical

How to test

• pnpm test:integration indexing scenarios all pass — build, gitignore-robust, neighborhood, incremental, blast-hub, precise, cochange-inc, worktree-seed (the incremental + worktree-seed paths exercise the same insertMany).
• pnpm test:unit (554) + pnpm typecheck + pnpm build green.
• Manual: plex index <large-repo> — seconds instead of a minute-plus; the graph counts are unchanged.

Notes

Found during the launch-readiness audit (npm advisories came back clean; error/empty states are mostly good). One minor UX item noted for a follow-up: plex review with nothing staged dumps the full agent-notes context instead of a clean "nothing to review" message.

🤖 Generated with Claude Code

[sshanzel]

Plex review feedback addressed — ready for re-review.

The Plex review (in-session) raised 1 nit + 2 improvements — all about the transaction wrap's interaction with callers and its atomicity claim, not the perf change itself.

Item	Class	Outcome
3. Whole batch in one transaction → unbounded WAL/undo on a huge monorepo	nit	Fixed in 50cd2e9: commit per CHUNK (10k rows) and re-BEGIN. The ~17× win holds (playright's largest batch <5k rows still commits once — normal repos unchanged); only >10k-row batches split, bounding the buffer.
1. "Atomic — rolls back instead of a half-written graph" overclaimed	improvement	Fixed in 50cd2e9: reworded to scope this as a PERF change. Callers issue several insertManys and the incremental DETACH DELETE auto-commits before the re-insert, so delete+reinsert was never one unit (and wasn't pre-PR); a partial build is recovered by the next full rebuild (sweep GraphFreshness / fresh index). True delete+reinsert atomicity (an outer transaction) would nest — deferred.
2. A thrown COMMIT / failed ROLLBACK could wedge the reused connection	improvement	Fixed in 50cd2e9: ROLLBACK only when a transaction is open (inTxn guard) so a BEGIN failure doesn't spawn a spurious rollback; documented that ROLLBACK closes the txn so the reused long-lived connection isn't left mid-transaction (which would make the next insertMany's BEGIN fail with an unrelated error), while the ORIGINAL error is surfaced.

Re-measured: playright (1328 files) still 5.08s — chunking doesn't regress normal repos.

Tests: insertMany is a Kùzu-opening core path (not unit-testable, ADR-17); covered by the indexing integration scenarios (build, gitignore-robust, incremental, worktree-seed — the incremental + worktree paths use the same insertMany), all green, plus the empirical playright re-index (identical graph: 1328 files / 4759 symbols / 4255 imports).

Checks: pnpm typecheck, pnpm test:unit (554), pnpm build, indexing scenarios — all green.

No GitHub review threads existed to reply to/resolve (the review was in-session).