Make drop_team_data_source migration idempotent #479
No reviewers
Labels
No labels
Kestra
bug
enhancement
someday
subtask
☁️ api
🎛️ infrastructure
🐞 sentry
📆 2025 Season
📝 pages
allpicks
📝 pages
picks
📝 pages
standings
🚀 performance
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
johnsturgeon/tgfp-web!479
Loading…
Reference in a new issue
No description provided.
Delete branch "fix-drop-team-data-source-migration-idempotent"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
resolves #480
Problem
Production crashed running migrations:
The migration
a390332fa722ran an unconditionalop.drop_column('team', 'data_source'), but no migration in the chain ever creates that column. The Alembic baseline (0c2ed4448b99) was auto-generated on 2026-08-31, after the Tank01 refactor (302663c, 2026-08-28) removeddata_sourcefrom theTeammodel — so the baseline codifies ateamtable without the column. Any database built from the chain createsteamwithoutdata_sourceand then tries to drop it → crash.Fix
Use
ALTER TABLE team DROP COLUMN IF EXISTS data_source, which:Version bumped 2.30.0 → 2.30.1. Tests: 314 passed, pylint 10.00/10.
🤖 Generated with Claude Code
The team model has no
data_sourcecolumn (confirmed), anda390332fa722is the head migration. The fix is sound.This change makes a crash-on-deploy migration idempotent by switching an unconditional
op.drop_columntoALTER TABLE team DROP COLUMN IF EXISTS data_source, which is correct PostgreSQL and safely no-ops on baseline-built databases while still dropping the column on pre-baseline snapshots. The diagnosis in the PR description matches the code, the version was bumped per convention (2.30.0 → 2.30.1in bothpyproject.tomlanduv.lock), and this looks good to merge.Nits
alembic/versions/a390332fa722_drop_team_data_source.py:33— Thedowngrade()re-adds the column unconditionally, so it's now asymmetric with the idempotentupgrade(): on a database built from the current baseline the upgrade is a no-op, but a subsequent downgrade would create adata_sourcecolumn that never existed there. This is harmless in practice (downgrading this migration is not something production does, and reverting to the "pre-migration state" is arguably the point), so it's not worth blocking on — but if you want strict symmetry,op.execute("ALTER TABLE team ADD COLUMN IF NOT EXISTS data_source VARCHAR NOT NULL DEFAULT ''")would mirror the guard.