Summary
alembic downgrade base fails on Postgres at revision v5o6b7s8d9e0:
constraint "fk_entity_project_id" ... does not exist
Origin is the batch-mode downgrades in 9d9c1cb7d8f5 / a1b2c3d4e5f6. Alembic's batch mode is a SQLite compatibility mechanism — it recreates the table — and the emitted downgrade does not match what Postgres actually has.
Provenance
Found while verifying the migration in PR #1444 (#1437). Confirmed pre-existing by reproducing it independently of that branch, and deliberately left untouched there so the fix would not ride along inside an unrelated change.
Why it is worth tracking
Upgrades work, so this does not affect normal operation. It matters for:
- rolling back a bad deploy on a hosted tenant
- any tooling that verifies migrations by walking the chain in both directions
The second is the reason it stayed invisible: the test suite uses create_all plus a stamp, so it never runs migrations at all. That gap has now produced two separate surprises in this campaign — this, and a SQLite batch-mode recreate that emitted sa.Computed columns twice and broke two pre-existing downgrade tests (fixed in #1440).
Direction
Fix the two batch-mode downgrades so they are correct on Postgres, or make them dialect-aware, since batch mode is only needed for SQLite.
Worth considering alongside it: a test that walks base → head → base on both backends. Nothing currently exercises migrations, which is why defects here surface only when someone verifies by hand.
Summary
alembic downgrade basefails on Postgres at revisionv5o6b7s8d9e0:Origin is the batch-mode downgrades in
9d9c1cb7d8f5/a1b2c3d4e5f6. Alembic's batch mode is a SQLite compatibility mechanism — it recreates the table — and the emitted downgrade does not match what Postgres actually has.Provenance
Found while verifying the migration in PR #1444 (#1437). Confirmed pre-existing by reproducing it independently of that branch, and deliberately left untouched there so the fix would not ride along inside an unrelated change.
Why it is worth tracking
Upgrades work, so this does not affect normal operation. It matters for:
The second is the reason it stayed invisible: the test suite uses
create_allplus a stamp, so it never runs migrations at all. That gap has now produced two separate surprises in this campaign — this, and a SQLite batch-mode recreate that emittedsa.Computedcolumns twice and broke two pre-existing downgrade tests (fixed in #1440).Direction
Fix the two batch-mode downgrades so they are correct on Postgres, or make them dialect-aware, since batch mode is only needed for SQLite.
Worth considering alongside it: a test that walks
base → head → baseon both backends. Nothing currently exercises migrations, which is why defects here surface only when someone verifies by hand.