Bug Description

gbrain search on PGLite still prints results and then hangs indefinitely on latest master / 0.37.10.0. This appears to be the same failure class as #1247, but I am opening a focused issue because it still reproduces on the current changelog head and blocks production upgrade from 0.36.6.0.

The key point: result generation is not the slow part. The rows are printed promptly, then the short-lived CLI process never exits.

Why this matters

This blocks upgrading a production PGLite brain from 0.36.6.0 to current master. 0.36.6.0 exits cleanly on the same corpus and command shapes. Current master does not.

Environment

• OS: macOS / Darwin arm64
• Runtime: Bun via local source checkout
• Engine: PGLite
• Current production version that works: gbrain 0.36.6.0
• Canary version that fails: gbrain 0.37.10.0
• Upstream commit tested: a55de712
• Canary setup: copied an existing PGLite GBrain home into an isolated GBRAIN_HOME, then ran latest source via bun src/cli.ts

Baseline: 0.36.6.0 works

Production pinned 0.36.6.0 exits normally:

gbrain --version
# gbrain 0.36.6.0

gbrain search "<redacted real query>" --limit 3
# exits in about 0.24s

gbrain search "test" --limit 1
# exits in about 0.31s

gbrain query "<redacted real query>" --limit 3
# exits normally

gbrain get <redacted-existing-slug>
# exits normally

Reproduction on latest master / 0.37.10.0

Using a local source checkout:

git clone https://github.com/garrytan/gbrain.git /tmp/gbrain-master
cd /tmp/gbrain-master
bun install
GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts --version
# gbrain 0.37.10.0

Then:

GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts search "<redacted real query>" --limit 3

Observed:

[score] <redacted-slug-1> -- <redacted excerpt>
[score] <redacted-slug-2> -- <redacted excerpt>
[score] <redacted-slug-3> -- <redacted excerpt>

The results print promptly, but the process does not exit. In my harness it had to be killed after an 8s timeout.

Same behaviour:

GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts search "test" --limit 1

Observed: one result prints promptly, then the process hangs until killed.

Controls that still pass on the same canary

These command shapes exit normally on the same copied PGLite brain under 0.37.10.0:

GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts query "<redacted real query>" --limit 3
GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts get <redacted-existing-slug>
GBRAIN_HOME=/path/to/isolated-canary-home bun src/cli.ts stats

So the failure looks specific to the CLI search lifecycle after printing results, not the underlying search result computation.

Source-level suspicion

The latest source still appears to have the same risky lifecycle:

• src/core/last-retrieved.ts documents bumpLastRetrievedAt(...) as fire-and-forget.
• src/core/operations.ts calls bumpLastRetrievedAt(ctx.engine, results.map(...)) after search results are generated.
• The short-lived CLI then disconnects the engine.

That matches the symptom: print results, schedule background retrieval-tracking write, then hang during or after disconnect on PGLite.

Expected behaviour

gbrain search ... should print results and exit cleanly, as it does on 0.36.6.0.

Actual behaviour

On latest master / 0.37.10.0, gbrain search ... prints results and then hangs until killed.

Suggested fix direction

Please consider making retrieval-tracking writes lifecycle-aware for short-lived local CLI / PGLite paths. Options:

1. Have bumpLastRetrievedAt(...) return a promise and await/drain it before engine.disconnect() in short-lived CLI commands.
2. Keep fire-and-forget only for long-lived MCP/server contexts.
3. Track pending last-retrieved writes centrally, similar to any existing pending-write drain, and drain before disconnect.

A regression test should assert that a PGLite CLI search command exits after printing results when retrieval tracking is enabled.

Related

Likely related to #1247, but confirmed still reproducible on 0.37.10.0 / commit a55de712.