[jalagrange]

Problem

Companion to #1593 — that PR repairs the batch-retry path so existing data loss stops. This PR fixes the root cause: a temp engine that joins the shared module-level singleton silently kills it for the whole cycle on disconnect().

Repro (full dream cycle on direct Postgres)

1. Cycle's main engine connects without poolSize → module path. db.ts singleton initialized; _connectionStyle='module'.
2. Lint phase's resolveLintContentSanity (src/commands/lint.ts:298) creates a temp PostgresEngine to read 4 config keys, calls engine.connect({}).
3. db.connect() no-ops because singleton is already alive. Temp engine sets _connectionStyle='module' regardless — even though it did nothing.
4. Lint's try/finally calls await engine.disconnect() on the temp engine. Pre-fix: falls through to db.disconnect() because _connectionStyle === 'module' — and silently nulls the shared singleton for the rest of the cycle.
5. sync, synthesize, and embed phases that run AFTER lint flunk with "No database connection: connect() has not been called."

extract survives because #1593's batchRetry onRetry calls this.reconnect() — but the non-batch phases have no such cushion.

Live evidence

Traced db.disconnect() on a v0.41.26.0 install with a temporary stack-trace probe:

[DBG] db.disconnect called, sql=alive
Error
    at disconnect (db.ts:228)
    at disconnect (postgres-engine.ts:211)
    at resolveLintContentSanity (lint.ts:319)
    at async runLintCore (lint.ts:395)
    at async runPhaseLint (cycle.ts:676)
    at async runCycle (cycle.ts:1421)

The first db.disconnect() of the cycle comes from lint, not from anything the cycle author would expect.

Fix

Track per-engine whether THIS instance actually initialized the singleton (_ownsModuleSingleton) by snapshotting db.isConnected() BEFORE calling db.connect(). Only the initializer is allowed to call db.disconnect() on cleanup. Joiners no-op — the CLI's main engine retains exclusive teardown rights.

Two-file change

src/core/db.ts — export new helper isConnected():

export function isConnected(): boolean {
  return sql !== null;
}

src/core/postgres-engine.ts — track ownership in connect(), gate teardown in disconnect():

+ private _ownsModuleSingleton = false;

  async connect(...) {
    ...
    } else {
+     const singletonWasLive = db.isConnected();
      await db.connect(config);
      this._connectionStyle = 'module';
+     this._ownsModuleSingleton = !singletonWasLive;
    }
  }

  async disconnect() {
    ...
    if (this._connectionStyle === 'module') {
+     if (this._ownsModuleSingleton) {
        await db.disconnect();
+     }
      this._connectionStyle = null;
+     this._ownsModuleSingleton = false;
    }
  }

Tests

test/postgres-engine-module-ownership.test.ts pins the contract hermetically via mock.module on db.ts. Four cases:

• first engine initializes; joiner does NOT disconnect on cleanup
• joiner.disconnect() BEFORE primary.disconnect() leaves singleton alive (the exact lint-phase repro)
• joiner.disconnect() is idempotent
• solo engine round-trips correctly

$ bun test test/postgres-engine-module-ownership.test.ts
 4 pass, 0 fail, 16 expect() calls

$ bun test test/postgres-engine-module-ownership.test.ts test/engine-factory.test.ts \
          test/connection-resilience.test.ts test/connection-manager.serial.test.ts \
          test/core/retry.test.ts
 99 pass, 0 fail

$ bun run typecheck  # clean

End-to-end verification

Deployed both PRs to the same install + ran gbrain dream:

Before (master + nothing):

✗ sync         sync phase failed
   [InternalError/UNKNOWN] No database connection: connect() has not been called.
✗ synthesize   synthesize phase failed
   [InternalError/SYNTH_PHASE_FAIL] No database connection: connect() has not been called.
✓ extract     285 link(s), 0 timeline entries  ← 13 rows lost in batch

After (PR #1593 + this PR):

✓ sync         +0 added, ~0 modified, -0 deleted
✓ synthesize   73 transcript(s) synthesized in 0.4s     ← drained the backlog
✓ extract      285 link(s), 37 timeline entries         ← full recovery

Zero "No database connection" in the log. The remaining ✗ embed is an unrelated OPENAI_API_KEY config issue, not the singleton bug.

Why ship both PRs

#1593 and this PR are independently load-bearing:

• This PR alone — batchRetry's pre-existing retry loop has no reconnect, so even though the singleton no longer dies mid-cycle, any real (non-leak) connection blip still loses batches. #1593 is the defense-in-depth.
• #1593 alone — extract recovers, but sync and synthesize keep flunking on every cycle. This PR is the root-cause fix.

Either can land first; merging both gives a fully clean cycle.

Risk

Minimal — the only behavior change is that passive sharers stop tearing down the shared pool. The CLI's main engine, autopilot's long-lived engine, and any first-connecting engine still teardown exactly as before. Second/third-connecting engines (lint's content-sanity, frontmatter audit, any future similar pattern) now correctly no-op on cleanup.

[garrytan]

Thanks for this! The Postgres module-singleton / "connect() has not been called" ownership bug was fixed canonically in #1805 (atomic owner-only-disconnect), with follow-ups in #1608 and #1572 — all merged to master. Closing as already-resolved. If you still reproduce after upgrading, please reopen, and thank you for the contribution.