Repository navigation
fix(db): resolve goose version collision between today's migrations - #3369
Conversation
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit 61bac1d. Bugbot is set up for automated code reviews on this repo. Configure here. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
LGTM — straightforward rename of a migration file to fix the goose version collision.
Extended reasoning...
Overview
This PR renames a single migration file, 20260723120000_rename_default_team_names_to_project.sql → 20260723172400_rename_default_team_names_to_project.sql, to resolve a duplicate goose version number that was colliding with another migration (set_tier_max_disk_size) merged around the same time. The diff is a pure rename (100% similarity), no SQL content changed.
Security risks
None. No logic, query, or schema change — only the migration's version-number filename changes.
Level of scrutiny
Low. I verified the fix is complete: packages/db/migrations/ now contains exactly one file per timestamp in that range (20260723120000_set_tier_max_disk_size.sql and 20260723172400_rename_default_team_names_to_project.sql), so the collection collision is resolved. The PR description's safety argument is sound: since goose panics on collection when versions collide, no environment could have applied the migration under its old version number, so renumbering carries no risk of an environment tracking two different applied-version records for the same migration.
Other factors
This is a build-unblocking hotfix (referenced as the root cause of ARM64 test-shard failures on open PRs and deploy-time migration failures). It's already merged into main per the local git log (61bac1d), consistent with the urgency described. Mechanical, single-file rename with no ambiguity.
…ations" (#3369) (#3378) #3366 had already resolved the 20260723120000 collision (renaming to 20260723120001) before #3369 merged its parallel rename to 20260723172400, so #3369's net effect on main was only adding a second copy of the same migration, which goose then applies twice. Reverting removes the duplicate; double-application was verified harmless (IF NOT EXISTS backup table, zero-row second pass), and environments that recorded 20260723172400 as applied keep a stale version row goose tolerates. Supersedes #3377.
…d siblings (#3387) The three same-morning autovacuum migrations merged in reverse timestamp order — envs (…051152) and snapshots (…051151) landed ~4h before env_build_assignments (…051130). Any database that migrated in that window is at …051152 and goose (no -allow-missing) now refuses with 'found 1 missing migrations before current version'. Renaming the eba migration to a fresh timestamp converges every state: databases past …051152 apply it next; databases that already applied …051130 (fresh CI DBs) re-apply it, which is safe — ALTER TABLE SET storage parameters is idempotent; databases before all three (production) apply everything in clean order and never see the gap. Same remedy class as the #3369 collision. File content unchanged.
Two migrations merged today share the goose version
20260723120000(set_tier_max_disk_sizefrom #3350 andrename_default_team_names_to_projectfrom #3334). Goose panics on duplicate versions at collection time, so since the second merge every goose invocation fails — all DB-touching test shards on every open PR, and any deploy-time migration step.Renumbers the later-merged one to
20260723172400(its merge time). This is safe precisely because of the failure mode: no goose run since the collision could have applied it anywhere, so no environment has it recorded under the old version; the earlier migration keeps its number and its applied history.Flagging as the likely root cause of ARM64 test-shard failures on currently-open PRs (observed on #3368) and of any migration-step failures in deploys since 17:24Z.