Two unrelated bugs reported from real Postgres/Supabase brains.

#1633 — gbrain sync spins, ignores SIGTERM, orphans pile up under cron

A sync --source <id> could enter a busy loop that pegs a CPU core and ignores SIGTERM/kill (only kill -9 stopped it). Under cron the stuck process orphaned and the next tick spawned another — one reporter found 13, 24h+ old. Root cause: a spinning sync starves its own event loop, so the SIGTERM handler and --timeout gbrain already had can never run.

Fix — out-of-band hard-deadline watchdog. src/core/process-watchdog.ts spawns a Bun worker_threads Worker (eval:true so it survives bun --compile) on a separate OS thread; at the deadline it SIGTERMs its own process, and at deadline+grace SIGKILLs it — fires even when the main loop is starved. Signals SELF, so no PID-reuse footgun. Empirically validated on Bun 1.3.13 (worker timer + SIGKILL killed a while(true){}-starved process; Codex outside-voice + a repo spike both confirmed).

• Armed in cli.ts before connectEngine so a connect-phase hang is bounded too.
• Non-TTY (cron) default 3600s; tune via GBRAIN_SYNC_MAX_RUNTIME_SECONDS, --hard-deadline <s>, or opt out with --no-hard-deadline. --timeout <s> auto-arms the hard backstop. Interactive TTY runs stay unbounded.
• Part B: SIGINT graceful-cancel on single-source + --all (Ctrl-C returns a clean partial + releases the lock via the normal finally, instead of a hard cut that leaked the lock). withRefreshingLock timer unref'd.
• The spin itself is not root-caused (needs a live repro; leading suspect is ReDoS in a schema-pack link rule, partly mitigated by v0.41.37.0's redos-guard). The watchdog makes the orphan-pileup/unkillable symptom impossible; gbrain sync --source <id> spins indefinitely (busy loop, SIGTERM ignored) → orphaned processes pile up under scheduler #1633 stays open for the root cause. A [sync-watchdog] heartbeat + the existing [gbrain phase] lines pinpoint the next hang.

#1768 — links_extraction_lag stuck at 100% on Postgres

gbrain extract --stale stamped every page, yet gbrain doctor still reported every page as needing extraction — the remediation it recommends could never satisfy its own check. Root cause: the stamp went through a JS Date (millisecond-truncated) while the DB updated_at keeps microseconds, so updated_at > links_extracted_at stayed permanently true. (Not a trigger — there is no BEFORE UPDATE trigger on pages.)

Fix. Both engines' listStalePagesForExtraction SELECT now projects a deterministic full-µs UTC string (to_char(updated_at AT TIME ZONE 'UTC', '…US"Z"')); StalePageRow.updated_at_iso; extractStaleFromDB stamps that. The markPagesExtractedBatch SQL is unchanged, so backdated stamps (version-arm test) still work and the CDX-1 edited-since arm is strengthened to exact equality. Postgres-only symptom.

Tests

• New: test/process-watchdog.test.ts (pure decision matrix + handle contract), test/process-watchdog.serial.test.ts (Bun-pinned: starved process IS killed ~deadline+grace; no-watchdog control does NOT self-exit; clean dispose never kills), test/sync-hard-deadline.test.ts (resolution precedence + composeAbortSignals).
• New deterministic µs regression in test/extract-stale.test.ts (inject a µs updated_at, run --stale, assert lag → 0 and stays 0).
• verify 29/29; typecheck clean; targeted post-merge suites 187 pass.

Pre-existing failures (NOT from this branch)

The full suite shows 4 failures in test/facts-classify.test.ts (×2) and test/mcp-eval-capture.test.ts (×2). Verified against a clean origin/master checkout: the same 4 fail there too — they predate this branch and live in areas this PR never touches (facts classifier, op-layer eval-capture). This PR adds 187+ passing tests and introduces zero new failures.

Reviews

/plan-eng-review CLEAR (9 decisions resolved) · /codex outside-voice CLEAR (validated both load-bearing bets: the to_char µs round-trip and the Bun worker-self-kill).

🤖 Generated with Claude Code