Summary

Two chicken-and-egg bugs that block bun install -g github:garrytan/gbrain upgrades from ancient versions. Both observed migrating a real 0.5.0 brain (2,748 pages, production) to 0.14.1 on 2026-04-20.

Bug 1 — idx_links_source tries to index a column that doesn't exist yet

CREATE TABLE IF NOT EXISTS links is a no-op on any pre-v0.11 links table (pre-v0.11 had no link_source / origin_page_id / origin_field columns). The very next line — CREATE INDEX IF NOT EXISTS idx_links_source ON links(link_source) — then errors out with column "link_source" does not exist.

src/core/migrate.ts v11 would add those columns via ALTER TABLE links ADD COLUMN IF NOT EXISTS link_source …, but the v0.11.0 migration orchestrator runs gbrain init --migrate-only (which runs schema.sql) as Phase A — before v11 gets a chance. So on any sufficiently old brain, Phase A fails with:

column "link_source" does not exist
Phase A (schema) failed: Command failed: gbrain init --migrate-only. Aborting; re-run after fixing.
Migration v0.11.0 reported status=failed.

Fix: add idempotent ALTER TABLE … ADD COLUMN IF NOT EXISTS inline in schema.sql, between the from/to index creates and the source/origin index creates. No-op on fresh brains (the CREATE TABLE above already has the columns). Self-heals old brains so the CREATE INDEX lines below succeed.

Bug 2 — const GBRAIN = process.execPath resolves to bun, not to gbrain

For bun install -g github:… installs, ~/.bun/bin/gbrain is a symlink to src/cli.ts and bun is the running process. So process.execPath is /root/.bun/bin/bun. The v0.13.0 Phase B backfill then runs:

execSync(`${GBRAIN} extract links --source db --include-frontmatter`)
# → bun extract links --source db --include-frontmatter

…which bun interprets as "run script extract from package.json" and fails with error: Script not found "extract". Migration reports PARTIAL, gbrain doctor flips minions_migration: fail, and gbrain apply-migrations --yes loops forever because every re-run hits the same wall.

Fix: detect bun-TS mode via process.argv[1].endsWith('.ts') and build the command as ${execPath} ${scriptPath} in that case (→ bun /path/to/cli.ts extract links …, which bun executes correctly). In bun build --compile mode the check is false and GBRAIN stays process.execPath as originally intended. Original concern about PATH shadowing is preserved in the comment — this just adds a branch for the bun-TS install path.

Test plan

• Fresh Postgres install: gbrain init → gbrain apply-migrations --yes — no regression (defensive ALTERs are no-ops on a fresh links table).
• Pre-v0.11 Postgres brain (simulate by dropping link_source / origin_page_id / origin_field): gbrain apply-migrations --yes — Phase A now passes, v0.13.0 Phase B now passes, migration completes.
• Compiled binary mode: bun build --compile … && ./bin/gbrain apply-migrations --yes — GBRAIN resolves to the compiled binary (argv[1] is not .ts), no regression in compiled path.

Workaround the downstream user applied

Until this merges, the manual patch is:

ALTER TABLE links ADD COLUMN IF NOT EXISTS link_source TEXT;
ALTER TABLE links ADD CONSTRAINT links_link_source_check CHECK (link_source IS NULL OR link_source IN ('markdown','frontmatter','manual'));
ALTER TABLE links ADD COLUMN IF NOT EXISTS origin_page_id INTEGER REFERENCES pages(id) ON DELETE SET NULL;
ALTER TABLE links ADD COLUMN IF NOT EXISTS origin_field TEXT;

plus sed -i 's/const GBRAIN = process.execPath;/const GBRAIN = "gbrain";/' src/commands/migrations/v0_13_0.ts in the installed copy (which a reinstall re-breaks).

🤖 Generated with Claude Code