fix(migrations): replace placeholder revision ID in granular export migration#40134
fix(migrations): replace placeholder revision ID in granular export migration#40134sadpandajoe wants to merge 1 commit into
Conversation
Code Review Agent Run #2076Actionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #40134 +/- ##
=======================================
Coverage 64.17% 64.17%
=======================================
Files 2590 2590
Lines 138087 138087
Branches 32039 32039
=======================================
Hits 88615 88615
Misses 47947 47947
Partials 1525 1525
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…igration The migration added in #38361 used a placeholder Alembic revision ID (a1b2c3d4e5f6) instead of a properly generated one. Replace it with a real random hex ID and update the downstream migration's down_revision. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
6b912ba to
594a9e9
Compare
| # revision identifiers, used by Alembic. | ||
| revision = "ce6bd21901ab" | ||
| down_revision = "a1b2c3d4e5f6" | ||
| down_revision = "41292324bf4e" |
There was a problem hiding this comment.
Suggestion: Changing the parent revision to a brand-new ID breaks upgrade continuity for any environment currently stamped at the old placeholder revision (a1b2c3d4e5f6): Alembic will fail because the current DB revision no longer exists in the script directory. Preserve compatibility by keeping a legacy revision node (or adding a bridge migration) so both already-migrated and fresh environments can upgrade without manual stamping. [api mismatch]
Severity Level: Major ⚠️
- ❌ Alembic upgrade fails from databases stamped old placeholder revision.
- ⚠️ Deployment pipeline requires manual alembic stamp to recover upgrades.Steps of Reproduction ✅
1. Note the new parent revision chain in the PR code:
-
`superset/migrations/versions/2026-03-02_12-00_41292324bf4e_add_granular_export_permissions.py`
defines `Revision ID: 41292324bf4e` and `down_revision = "4b2a8c9d3e1f"` (verified via
Grep: lines 19–21 and 26–27).
-
`superset/migrations/versions/2026-03-02_00-00_ce6bd21901ab_migrate_deckgl_and_mapbox.py`
defines `revision = "ce6bd21901ab"` and at line 47 (in this PR hunk) sets
`down_revision = "41292324bf4e"`.
2. Confirm that the previous placeholder revision ID no longer exists in the migration
scripts:
- A repo-wide Grep for `a1b2c3d4e5f6` under `/workspace/superset` returns no matches,
so there is no migration file whose `revision` equals `a1b2c3d4e5f6`.
3. Consider an environment that previously ran the original migration from PR #38361
before this fix:
- In that environment, the Alembic `alembic_version` table was stamped to the
placeholder revision ID `a1b2c3d4e5f6` (the old revision value that this PR replaces
with `41292324bf4e`).
- After deploying this PR's code (which only knows `41292324bf4e` and has
`down_revision = "41292324bf4e"` at line 47), the database still reports `a1b2c3d4e5f6`
as its current revision.
4. Run the standard migration upgrade command (e.g. `superset db upgrade`, which drives
Alembic using the script directory `superset/migrations/versions`):
- Alembic reads the current DB revision `a1b2c3d4e5f6` from `alembic_version`, then
looks for a migration script with `revision = "a1b2c3d4e5f6"`.
- Because that revision no longer exists in the script directory (step 2), Alembic
raises a `RevisionError` like "Can't locate revision identified by 'a1b2c3d4e5f6'",
blocking upgrades until an operator manually runs `alembic stamp 41292324bf4e` or
equivalent.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** superset/migrations/versions/2026-03-02_00-00_ce6bd21901ab_migrate_deckgl_and_mapbox.py
**Line:** 47:47
**Comment:**
*Api Mismatch: Changing the parent revision to a brand-new ID breaks upgrade continuity for any environment currently stamped at the old placeholder revision (`a1b2c3d4e5f6`): Alembic will fail because the current DB revision no longer exists in the script directory. Preserve compatibility by keeping a legacy revision node (or adding a bridge migration) so both already-migrated and fresh environments can upgrade without manual stamping.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fixThere was a problem hiding this comment.
Doesn't alembic work by figuring out what the current version is and either
- if it is ahead do nothing on upgrades, can trace for down grades
- if behind, it'll just upgrade the current version
- if it is the exact, is where we might have a problem, but should be pretty easy to get around that.
There was a problem hiding this comment.
Not quite — Alembic does not treat this as “if it’s ahead, do nothing.”
It first reads the DB’s current revision from alembic_version and then tries to find that exact revision node in the migration graph. So if an environment is stamped with a1b2c3d4e5f6 and that revision no longer exists in the scripts, Alembic can’t build the path and will fail before it can decide what to upgrade.
Why this PR’s change is risky
Changing:
down_revision = "a1b2c3d4e5f6"to:
down_revision = "41292324bf4e"fixes the chain for new installs, but it breaks existing databases that already recorded the old placeholder revision.
Safer fix
Keep a legacy node for a1b2c3d4e5f6 in the migration history, or add a bridge migration that preserves the old revision ID and points forward to the new one. That way both cases work:
- old deployments can still resolve their current revision
- fresh deployments follow the corrected chain
Conclusion
So the issue raised in the review is valid: Alembic needs the old revision to remain reachable. If you want, I can help suggest the smallest bridge-migration approach to preserve compatibility without manual stamping.
|
The flagged issue is correct: replacing the placeholder revision ID 'a1b2c3d4e5f6' with '41292324bf4e' breaks upgrade continuity for databases already stamped with the old ID, as Alembic won't find the old revision. To resolve, create a no-op legacy migration with revision 'a1b2c3d4e5f6' and update the down_revision in the '41292324bf4e' file to reference it, maintaining the chain. There are no other comments on this PR. superset/migrations/versions/2026-03-02_12-00_a1b2c3d4e5f6_add_granular_export_permissions.py superset/migrations/versions/2026-03-02_12-00_41292324bf4e_add_granular_export_permissions.py |
Code Review Agent Run #80dd08Actionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
|
This looks good, but I wouldn't merge it — there's nothing wrong with using |
|
closing |
Summary
The migration added in #38361 (
add_granular_export_permissions) used a placeholder Alembic revision ID (a1b2c3d4e5f6) instead of a properly generated one. This replaces it with a real random hex ID (41292324bf4e) and updates the downstream migration'sdown_revisionto match.Changes:
revisioninside the migration filedown_revisionin the downstreamce6bd21901abmigration (deck.gl/mapbox, feat: modernize deck.gl and map plugins with MapLibre/Mapbox dual renderer #38035)Migration chain (after fix):
Note for deployments already past this migration: The
alembic_versiontable only stores the current head, so databases that have already run all migrations will not be affected. Any database stopped exactly at the old revision would needalembic stamp 41292324bf4e.