fix(store): migration version collision — 0008_repo_secrets vs 0008_run_title breaks store.Open on main #115

New issue

Closed

opened 2026-07-10 19:30:33 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-07-10 19:30:33 +02:00

Owner

Both migrations/{sqlite,postgres}/0008_repo_secrets.sql (#104, merged in d4cfbde) and migrations/{sqlite,postgres}/0008_run_title.sql (#111, merged later in c95b8d5) claim goose version 8. The #111 branch was cut before #104 merged, so each branch was green in isolation; the collision only exists on merged main and nobody re-ran the suite post-merge.

Impact: goose.NewProvider rejects duplicate versions, so store.Open fails for BOTH dialects — the server cannot boot on current main, and every test that opens a store (internal/store, internal/labctl fixtures, internal/httpapi, …) fails with duplicate migration version 8. TestMigrationParity catches it: go test ./internal/store/ -run TestMigrationParity is red at c95b8d5.

Fix: rename 0008_run_title.sql → 0009_run_title.sql in both dialect directories (the later-merged migration yields). Safe for every real deployment lineage: goose records applied versions by number; any DB that migrated before the collision has 8 = repo_secrets (main lineage — #104 merged first), and no DB can have applied run_title as 8 because a tree containing both files fails at provider construction, before applying anything.

Found while shipping #105 (its verification requires a green suite). The rename is included as a separate fix(store) commit in the #105 PR so that PR can run green; this issue tracks the defect itself and closes with that PR.

Both `migrations/{sqlite,postgres}/0008_repo_secrets.sql` (#104, merged in d4cfbde) and `migrations/{sqlite,postgres}/0008_run_title.sql` (#111, merged later in c95b8d5) claim goose version 8. The #111 branch was cut before #104 merged, so each branch was green in isolation; the collision only exists on merged main and nobody re-ran the suite post-merge. Impact: `goose.NewProvider` rejects duplicate versions, so `store.Open` fails for BOTH dialects — the server cannot boot on current main, and every test that opens a store (`internal/store`, `internal/labctl` fixtures, `internal/httpapi`, …) fails with `duplicate migration version 8`. `TestMigrationParity` catches it: `go test ./internal/store/ -run TestMigrationParity` is red at c95b8d5. Fix: rename `0008_run_title.sql` → `0009_run_title.sql` in both dialect directories (the later-merged migration yields). Safe for every real deployment lineage: goose records applied versions by number; any DB that migrated before the collision has 8 = repo_secrets (main lineage — #104 merged first), and no DB can have applied run_title as 8 because a tree containing both files fails at provider construction, before applying anything. Found while shipping #105 (its verification requires a green suite). The rename is included as a separate `fix(store)` commit in the #105 PR so that PR can run green; this issue tracks the defect itself and closes with that PR.

dominik.polakovics added the

bug

label

2026-07-10 19:30:33 +02:00

dominik.polakovics referenced this issue from a commit

2026-07-10 19:35:21 +02:00

fix(store): renumber run_title migration to 0009 — version collision with repo_secrets (#115)

dominik.polakovics referenced this issue from a pull request that will close it,

2026-07-10 19:35:45 +02:00

feat(secrets): broker output redaction in labctl secret exec (#105) #116

dominik.polakovics closed this issue

2026-07-10 20:53:28 +02:00