Files
gbrain/test
Garry TanandClaude Opus 5 5cd0d6eddd fix(reindex-frontmatter): reuse the connected engine instead of self-deadlocking on the PGLite lock (#1963)
cli.ts's dispatch connects the primary engine (taking the PGLite data-dir
lock), then reindexFrontmatterCli built and connected a SECOND engine on
the same data dir. acquireLock never reaps a live PID — and the recorded
holder was this very process — so every 'gbrain reindex-frontmatter' on
PGLite spun the full 30s lock timeout and exited 1, reporting itself as
the blocking process. (The issue's statement_timeout theory was a red
herring: the backfill itself finishes in milliseconds.)

'gbrain backfill <kind>' had the identical double-connect and is fixed
the same way: both commands now take the already-connected engine from
the dispatch switch, and cli.ts's shared finally owns teardown.

Deliberately NOT changed: pglite-lock.ts. Making the lock reentrant (or
special-casing our own PID) would contradict the pinned #2348 semantics
— a live-PID holder is never stolen, PID-reuse included — and the root
cause is the second connect, not the lock.

Regression test spawns the real CLI against a fresh PGLite home
(init → import → reindex-frontmatter → backfill effective_date); on
master it fails after the 30s self-deadlock, with the fix it passes in
seconds.

Fixes #1963

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-28 16:47:15 -07:00
..