fix: reversed migration order #963
Conversation
WalkthroughThe order of two database migration steps in the system migrations file has been swapped. The migration that sets the default metadata on ledgers now follows the migration that adds the Changes
Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate Unit Tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
internal/storage/system/migrations.go (1)
240-247: Minor hardening: make the “set default” statement idempotent
ALTER TABLE … ALTER COLUMN … SET DEFAULTwill error if a different default is already present (unlikely, but possible in forks or manual hot-fixes).
You could guard the operation with a dynamic check:- _, err := tx.ExecContext(ctx, ` - alter table _system.ledgers - alter column metadata set default '{}'::jsonb; - `) + _, err := tx.ExecContext(ctx, ` + DO $$ + BEGIN + IF ( + SELECT pg_get_expr(adbin, adrelid) + FROM pg_attrdef + WHERE adrelid = '_system.ledgers'::regclass + AND adnum = ( + SELECT attnum + FROM pg_attribute + WHERE attrelid = '_system.ledgers'::regclass + AND attname = 'metadata' + ) + ) IS DISTINCT FROM '''{}''::jsonb' THEN + ALTER TABLE _system.ledgers + ALTER COLUMN metadata SET DEFAULT '{}'::jsonb; + END IF; + END$$; + `)Not strictly required but ensures full idempotency if someone tweaks the default out-of-band.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
internal/storage/system/migrations.go(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Tests
- GitHub Check: Dirty
🔇 Additional comments (1)
internal/storage/system/migrations.go (1)
231-238:❓ Verification inconclusive
Re-ordering is fine, but double-check migration history across environments
Because Bun keys migrations by name and stores every applied name in
_migrations, the swap will not re-execute anything that has already run.
However, if you have any database that:
- Ran only one of the two migrations (e.g. CI snapshot or a blue/green rollout paused between the two), and
- Has that migration recorded after the other in the
_migrationstable,then the new order could trigger an “unexpected migration” error.
Run the quick check below against an existing staging/prod database before shipping to be sure both names are present and in any order:
If both rows exist, you are safe; if only one row exists you may need a manual insert/delete.
No code change required, just operational awareness.
🏁 Script executed:
#!/bin/bash # List the two migrations and their applied order psql "$DATABASE_URL" -c \ "SELECT name, run_at FROM _migrations WHERE name IN ('Add json_compact function', 'set default metadata on ledgers') ORDER BY run_at;"Length of output: 258
Verify migration order in all environments
Reordering these two migrations is safe in code—Bun keys by migration name and won’t re-execute already applied names—but you must confirm your staging/prod databases haven’t applied only one of them in the “wrong” order, which would trigger an unexpected-migration error.
Please run this against each target database before deploying:
psql "$DATABASE_URL" -c \ "SELECT na 8000 me, run_at FROM _migrations WHERE name IN ( 'Add json_compact function', 'set default metadata on ledgers' ) ORDER BY run_at;"
- If you see both rows, in any order, you’re all set.
- If only one row appears, you’ll need to manually insert or remove the missing entry to realign the history.
No code changes are required—just operational awareness.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #963 +/- ##
==========================================
- Coverage 82.79% 82.72% -0.08%
==========================================
Files 142 142
Lines 8028 8028
==========================================
- Hits 6647 6641 -6
- Misses 1056 1060 +4
- Partials 325 327 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
No description provided.