init --migrate-only crashes on pre-v36 brains: column "provider_id" does not exist
Summary
Upgrading a brain from <v0.27 to v0.27+ via gbrain init --migrate-only aborts before the v36 migration runs, because PGLITE_SCHEMA_SQL is replayed at startup and creates indexes referencing columns that only the v36 migration adds.
Repro
- Brain at
schema_version = 35, gbrain CLI v0.26.x.
git pull to v0.27+ (introduces v36 migration: subagent_provider_neutral_persistence_v0_27, adds subagent_messages.provider_id and schema_version, plus matching columns on subagent_tool_executions).
gbrain init --migrate-only
Result
error: column "provider_id" does not exist
at ... CREATE INDEX … ON subagent_messages (job_id, provider_id)
The startup bootstrap aborts before runMigrations() gets a chance to add the column.
Root cause
src/core/pglite-engine.ts::applyForwardReferenceBootstrap is the existing pattern for reconciling PGLITE_SCHEMA_SQL with not-yet-applied migrations (it ALTERs the legacy tables to add columns the bootstrap SQL expects). When v36 added new provider_id / schema_version columns to subagent_messages and subagent_tool_executions and PGLITE_SCHEMA_SQL was extended to index them (see line ~339 of the schema string), applyForwardReferenceBootstrap was not extended to cover the new columns.
Result: any brain that was created on v0.26 or earlier, then upgraded to v0.27+ before running migrations, hits this on every subsequent init.
Workaround (manual)
ALTER TABLE subagent_messages
ADD COLUMN IF NOT EXISTS schema_version INTEGER NOT NULL DEFAULT 1,
ADD COLUMN IF NOT EXISTS provider_id TEXT;
ALTER TABLE subagent_tool_executions
ADD COLUMN IF NOT EXISTS schema_version INTEGER NOT NULL DEFAULT 1,
ADD COLUMN IF NOT EXISTS provider_id TEXT;
Then gbrain init --migrate-only succeeds and v36 records itself as applied.
Suggested fix
Extend applyForwardReferenceBootstrap to add the v36 columns the same way it handles the older forward refs. Optionally: have the bootstrap derive the required columns from the migration list rather than hard-coding them, so future migrations don't repeat this.
Environment
- gbrain v0.28.3 (also reproduces against any v0.27.x → v0.28.x upgrade from a pre-v36 brain)
- macOS 15 / arm64
- bun 1.x
- PGLite (default engine)
init --migrate-onlycrashes on pre-v36 brains:column "provider_id" does not existSummary
Upgrading a brain from <v0.27 to v0.27+ via
gbrain init --migrate-onlyaborts before the v36 migration runs, becausePGLITE_SCHEMA_SQLis replayed at startup and creates indexes referencing columns that only the v36 migration adds.Repro
schema_version = 35, gbrain CLI v0.26.x.git pullto v0.27+ (introduces v36 migration:subagent_provider_neutral_persistence_v0_27, addssubagent_messages.provider_idandschema_version, plus matching columns onsubagent_tool_executions).gbrain init --migrate-onlyResult
The startup bootstrap aborts before
runMigrations()gets a chance to add the column.Root cause
src/core/pglite-engine.ts::applyForwardReferenceBootstrapis the existing pattern for reconcilingPGLITE_SCHEMA_SQLwith not-yet-applied migrations (it ALTERs the legacy tables to add columns the bootstrap SQL expects). When v36 added newprovider_id/schema_versioncolumns tosubagent_messagesandsubagent_tool_executionsandPGLITE_SCHEMA_SQLwas extended to index them (see line ~339 of the schema string),applyForwardReferenceBootstrapwas not extended to cover the new columns.Result: any brain that was created on v0.26 or earlier, then upgraded to v0.27+ before running migrations, hits this on every subsequent
init.Workaround (manual)
Then
gbrain init --migrate-onlysucceeds and v36 records itself as applied.Suggested fix
Extend
applyForwardReferenceBootstrapto add the v36 columns the same way it handles the older forward refs. Optionally: have the bootstrap derive the required columns from the migration list rather than hard-coding them, so future migrations don't repeat this.Environment