mirror of
https://github.com/garrytan/gbrain.git
synced 2026-07-30 19:49:14 +00:00
Garry TanandClaude Opus 5
5cd0d6eddd
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>