Symptom
On a brain whose Postgres sits behind a Supabase transaction-mode pooler (port 6543), /sync-gbrain permanently skips the code + memory stages:
gstack-gbrain-sync (incremental):
SKIP code skipped — local engine broken-config — config at ~/.gbrain/config.json is malformed; see /setup-gbrain Step 1.5
SKIP memory skipped — local engine broken-config — ...
OK brain-sync curated artifacts pushed
…while the engine is in fact healthy: gbrain doctor is green and gbrain sources list --json returns valid JSON with exit 0. The config file is well-formed.
Root cause
lib/gbrain-local-status.ts classifies the engine by probing gbrain sources list --json with PROBE_TIMEOUT_MS = 5_000. On this setup a fresh CLI connection through the pooler takes 6.9–10.7s (measured across runs), so the probe times out every time. The timeout error's stderr matches neither "Cannot connect to database" nor "config.json", so the defensive default (codex #8) classifies it as broken-config — and the 60s cache then propagates the misdiagnosis to the orchestrator and every skill preamble.
The user-facing message ("config at ~/.gbrain/config.json is malformed") points at a file that is fine, so the remediation steps in /setup-gbrain Step 1.5 can't fix it.
Reproduce
Any gbrain on a connection where time gbrain sources list --json > 5s (e.g. Supabase transaction pooler from a residential connection). Then run /sync-gbrain → code+memory SKIP with broken-config.
Suggested fix (any of)
- Raise
PROBE_TIMEOUT_MS (20s covered my worst case), and/or
- Honor an env override (e.g.
GSTACK_GBRAIN_PROBE_TIMEOUT_MS) so slow-pooler users can tune it without patching the lib, and/or
- Classify the timeout case distinctly (e.g.
slow-engine) instead of falling into broken-config, with a message that names the real condition ("probe exceeded Ns — engine may be reachable but slow; raise the timeout").
Locally patching PROBE_TIMEOUT_MS 5000→20000 fully resolves it (sync runs all stages), but the patch is reverted by every git reset --hard upgrade.
Symptom
On a brain whose Postgres sits behind a Supabase transaction-mode pooler (port 6543),
/sync-gbrainpermanently skips the code + memory stages:…while the engine is in fact healthy:
gbrain doctoris green andgbrain sources list --jsonreturns valid JSON with exit 0. The config file is well-formed.Root cause
lib/gbrain-local-status.tsclassifies the engine by probinggbrain sources list --jsonwithPROBE_TIMEOUT_MS = 5_000. On this setup a fresh CLI connection through the pooler takes 6.9–10.7s (measured across runs), so the probe times out every time. The timeout error's stderr matches neither"Cannot connect to database"nor"config.json", so the defensive default (codex #8) classifies it asbroken-config— and the 60s cache then propagates the misdiagnosis to the orchestrator and every skill preamble.The user-facing message ("config at ~/.gbrain/config.json is malformed") points at a file that is fine, so the remediation steps in /setup-gbrain Step 1.5 can't fix it.
Reproduce
Any gbrain on a connection where
time gbrain sources list --json> 5s (e.g. Supabase transaction pooler from a residential connection). Then run/sync-gbrain→ code+memory SKIP with broken-config.Suggested fix (any of)
PROBE_TIMEOUT_MS(20s covered my worst case), and/orGSTACK_GBRAIN_PROBE_TIMEOUT_MS) so slow-pooler users can tune it without patching the lib, and/orslow-engine) instead of falling intobroken-config, with a message that names the real condition ("probe exceeded Ns — engine may be reachable but slow; raise the timeout").Locally patching
PROBE_TIMEOUT_MS5000→20000 fully resolves it (sync runs all stages), but the patch is reverted by everygit reset --hardupgrade.