fix(BA-6899): stop app_configs downgrade from creating its enum twice#12887
Conversation
The downgrade created app_config_scope_type twice within itself: once explicitly via create(checkfirst=True), and again implicitly when create_table() emitted CREATE TYPE for the column typed by that same Enum. The implicit one carries no existence check, so the downgrade aborted with DuplicateObjectError every time, blocking any downgrade that has to cross this revision. Drop the explicit create() and let create_table() create the type once. upgrade() already drops the type with DROP TYPE IF EXISTS, so the pair round-trips. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Fixes the legacy app_configs migration downgrade by preventing duplicate PostgreSQL enum creation.
Changes:
- Lets
op.create_table()createapp_config_scope_type. - Adds a changelog fragment for the downgrade fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
84d5c6daf8cc_drop_legacy_app_configs_table.py |
Removes redundant enum creation. |
changes/12887.fix.md |
Documents the migration fix. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
fregataa
left a comment
There was a problem hiding this comment.
I don't understand how duplicate error happens. It seems upgrade should drop the app config scope enum type properly
It's not that the enum wasn't removed during the upgrade. The issue is that the downgrade attempts to create the enum a second time. As a result, the downgrade fails even when the enum doesn't exist. @fregataa |
Problem
84d5c6daf8cc'sdowngrade()fails every time, on every database. Any downgrade that has to cross this revision is blocked.It creates
app_config_scope_typetwice within itself:upgrade()drops the type, so at this point it is absent and step 1 creates it. Step 2 then re-emitsCREATE TYPEfor the same enum with no existence check:This is not environment-specific and not an artifact of the one-shot bootstrap. On a clean DB built at head, with the enum confirmed absent (
ABSENT at head) and no model declaring it, stamping84d5c6daf8ccand running only its downgrade reproduces the failure deterministically.Fix
Delete the explicit
create()and letcreate_table()create the type once.upgrade()already doesDROP TYPE IF EXISTS, so the pair round-trips.Verification
Run against a real DB built at head, before and after:
downgrade 84d5c6daf8cc -> f3a8c1d05e64app_configsrestored, enum present,scope_typeisUSER-DEFINED/app_config_scope_typeupgradeback to84d5c6daf8ccdowngradea second timeFound while verifying the downgrade chain for #12881.
🤖 Generated with Claude Code