fix(browser-tabs): self-heal schema drift on every boot - #3420
Conversation
The 0020 repair migration is one-shot: once the ledger records it, a later table rebuild by another branch's build (the panes branch drops the target columns from browser_tabs) leaves every browser-tabs query throwing and the tab strip dead, a lone + that does nothing. Run an always-on heal after every migration pass instead, derived from the migration folder's latest drizzle meta snapshot so it can never drift from the real schema or resurrect columns a future migration deliberately drops. Missing nullable columns are added in place; a variant missing a structural NOT NULL column is rebuilt rather than stamped with fabricated defaults. Best-effort throughout: the heal can never turn a working boot into a failed one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
|
Reviews (1): Last reviewed commit: "fix(browser-tabs): self-heal schema drif..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| }); | ||
|
|
||
| applyPending(); | ||
| ensureBrowserTabsSchema(sqlite, migrationsFolder); |
There was a problem hiding this comment.
runMigrations now depends on the passed migration folder containing meta/_journal.json, but the production database service path is db-migrations while the checked-in folder used by tests is migrations. If that production path does not include the Drizzle meta snapshots, latestSnapshotTables returns null, this new boot-time heal silently does nothing, and the reported browser-tabs schema drift still reaches the ORM load at startup.
There was a problem hiding this comment.
false positive, no fix: copyDrizzleMigrations (apps/code/vite-main-plugins.mts:483) does cpSync of the entire migrations dir recursively, meta/ included — confirmed present in .vite/build/db-migrations/meta. And readMigrationFiles already requires the same meta/_journal.json, so any folder migrations can run from has the snapshot too
2 participants
Problem
Dev sqlite DBs are shared across branches. A build from the panes branch rebuilds
browser_tabswithout its target columns (dashboard_id/task_id/channel_id/channel_section/app_view/scroll_state), so back on main every browser-tabs query throws at boot and the tab strip renders a dead "+" that does nothing when clicked.The existing 0020 repair migration can't help here: it is one-shot. Once the ledger records it as applied, drift that happens afterward (exactly this case) never gets healed.
Changes
runMigrationsnow runsensureBrowserTabsSchemaafter every migration pass, an always-on boot invariant rather than a one-shot migration.ALTER TABLE ADD COLUMN; a variant missing a structural NOT NULL column is rebuilt (tabs are recoverable UI state) instead of stamping rows with fabricated defaults that would create dangling FK references; a non-table squatting on the name (e.g. a VIEW) is skipped.How did you test this?
migrate.test.tstests pass; fullworkspace-serversuite passes except a pre-existing environment-dependentarchive.integration.test.tscase (baregit tagfails undertag.gpgsign=truein the local gitconfig, unrelated to this change).Automatic notifications
🤖 Generated with Claude Code