fix(migration): dedup SQL migration versions - #4428
Merged
Merged
Conversation
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Summary by CodeRabbit
WalkthroughAdds persistent storage for BMC suppression requests and a migration test that detects duplicate versions across configured migrators. ChangesMigration integrity
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
jayzhudev
enabled auto-merge (squash)
July 31, 2026 02:02
Signed-off-by: Jay Zhu <jayzhu@nvidia.com>
jayzhudev
force-pushed
the
fix/db-migrations
branch
from
July 31, 2026 02:13
654ce83 to
bb771ad
Compare
10 tasks
10 tasks
chet
added a commit
that referenced
this pull request
Jul 31, 2026
…4432) PR #4389 and PR #4428 independently fixed the same duplicate migration version from opposite sides. The loopback preservation migration first reached `main` in #3913 as `20260722120000`, while the BMC suppression migration came later. #4428 correctly moved the newer BMC migration to `20260722120001`, but #4389 had already renamed the older loopback migration to that same version on an earlier base. Since #4428 merged first, #4389 left `main` with two `20260722120001` migrations and removed the identity existing databases may already have in `_sqlx_migrations`. So, restore `20260722120000_preserve_machine_ipv6_loopback.sql` and leave `20260722120001_bmc_suppressions.sql` where it is. The loopback migration SQL is byte-for-byte identical to #3913, existing database histories keep matching the published version and checksum, and SQLx sees each migration version exactly once again. ## Related issues None -- urgent post-merge repair for #4389 and #4428. ## Type of Change - [ ] **Add** - New feature or capability - [ ] **Change** - Changes in existing functionality - [x] **Fix** - Bug fixes - [ ] **Remove** - Removed features or deprecated functionality - [ ] **Internal** - Internal changes (refactoring, tests, docs, etc.) ## Breaking Changes - [ ] **This PR contains breaking changes** ## Testing - [ ] Unit tests added/updated - [ ] Integration tests added/updated - [x] Manual testing performed - [ ] No testing required (docs, internal refactor, etc.) ## Additional Notes - `cargo test -p carbide-api-db migrations::tests --lib` (4 passed) - `cargo make format-nightly` - `cargo make clippy` - `cargo make carbide-lints` - `git diff --check` - Restored migration blob matches the original #3913 blob exactly (`eaff208e4ea6d3956bdb158a84c45ee6c1362ecf`) - This restores the migration identities intended by #4428. A database first initialized during either brief duplicate-version window may have recorded the wrong checksum at `20260722120000` or `20260722120001`; inspect its schema and migration history and perform site-specific repair before retrying rather than blindly replaying these non-idempotent migrations Signed-off-by: Chet Nichols III <chetn@nvidia.com>
polarweasel
pushed a commit
to polarweasel/infra-controller
that referenced
this pull request
Jul 31, 2026
Two database migrations on `main` use SQLx version `20260722120000`. Because SQLx records migration versions as primary keys, fresh database migration fails when the second migration is recorded, blocking Core CI and dependent PRs. This change assigns the newer BMC suppression migration version `20260722120001` without changing its SQL content. It also adds a regression test covering all legacy, squash, and post-squash migrations so duplicate versions fail with a focused diagnostic. ## Related issues Resolves NVIDIA#4427 ## Type of Change - [ ] **Add** - New feature or capability - [ ] **Change** - Changes in existing functionality - [x] **Fix** - Bug fixes - [ ] **Remove** - Removed features or deprecated functionality - [ ] **Internal** - Internal changes (refactoring, tests, docs, etc.) ## Breaking Changes - [ ] **This PR contains breaking changes** ## Testing - [x] Unit tests added/updated - [ ] Integration tests added/updated - [x] Manual testing performed - [ ] No testing required (docs, internal refactor, etc.) ## Additional Notes Databases that recorded `preserve_machine_ipv6_loopback` as version `20260722120000` will apply the BMC suppression migration as `20260722120001` normally. Any database that already recorded `bmc_suppressions` as `20260722120000` requires migration-history repair before upgrading. Signed-off-by: Jay Zhu <jayzhu@nvidia.com> Signed-off-by: Alex Ball <aball@nvidia.com>
polarweasel
pushed a commit
to polarweasel/infra-controller
that referenced
this pull request
Jul 31, 2026
…VIDIA#4432) PR NVIDIA#4389 and PR NVIDIA#4428 independently fixed the same duplicate migration version from opposite sides. The loopback preservation migration first reached `main` in NVIDIA#3913 as `20260722120000`, while the BMC suppression migration came later. NVIDIA#4428 correctly moved the newer BMC migration to `20260722120001`, but NVIDIA#4389 had already renamed the older loopback migration to that same version on an earlier base. Since NVIDIA#4428 merged first, NVIDIA#4389 left `main` with two `20260722120001` migrations and removed the identity existing databases may already have in `_sqlx_migrations`. So, restore `20260722120000_preserve_machine_ipv6_loopback.sql` and leave `20260722120001_bmc_suppressions.sql` where it is. The loopback migration SQL is byte-for-byte identical to NVIDIA#3913, existing database histories keep matching the published version and checksum, and SQLx sees each migration version exactly once again. ## Related issues None -- urgent post-merge repair for NVIDIA#4389 and NVIDIA#4428. ## Type of Change - [ ] **Add** - New feature or capability - [ ] **Change** - Changes in existing functionality - [x] **Fix** - Bug fixes - [ ] **Remove** - Removed features or deprecated functionality - [ ] **Internal** - Internal changes (refactoring, tests, docs, etc.) ## Breaking Changes - [ ] **This PR contains breaking changes** ## Testing - [ ] Unit tests added/updated - [ ] Integration tests added/updated - [x] Manual testing performed - [ ] No testing required (docs, internal refactor, etc.) ## Additional Notes - `cargo test -p carbide-api-db migrations::tests --lib` (4 passed) - `cargo make format-nightly` - `cargo make clippy` - `cargo make carbide-lints` - `git diff --check` - Restored migration blob matches the original NVIDIA#3913 blob exactly (`eaff208e4ea6d3956bdb158a84c45ee6c1362ecf`) - This restores the migration identities intended by NVIDIA#4428. A database first initialized during either brief duplicate-version window may have recorded the wrong checksum at `20260722120000` or `20260722120001`; inspect its schema and migration history and perform site-specific repair before retrying rather than blindly replaying these non-idempotent migrations Signed-off-by: Chet Nichols III <chetn@nvidia.com> Signed-off-by: Alex Ball <aball@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two database migrations on
mainuse SQLx version20260722120000. Because SQLx records migration versions as primary keys, fresh database migration fails when the second migration is recorded, blocking Core CI and dependent PRs.This change assigns the newer BMC suppression migration version
20260722120001without changing its SQL content. It also adds a regression test covering all legacy, squash, and post-squash migrations so duplicate versions fail with a focused diagnostic.Related issues
Resolves #4427
Type of Change
Breaking Changes
Testing
Additional Notes
Databases that recorded
preserve_machine_ipv6_loopbackas version20260722120000will apply the BMC suppression migration as20260722120001normally. Any database that already recordedbmc_suppressionsas20260722120000requires migration-history repair before upgrading.