agent squashed migrations locally but production still runs the old files - how to reconcile

TL;DR

Squashing rewrites revision ids, but production's state table still references the old ids: the squash and production now disagree about history. The safe fix is to keep the old files until every environment has passed the squash point, or, when the squashed schema provably equals the old chain's result, stamp production to the new base. Never delete applied files to "complete" a squash.

The query

agent squashed migrations locally but production still runs the old files - how to reconcile

Use this when

• An agent squashed migrations that production already applied
• Production's state table references pre-squash revision ids
• Squash broke deploys to existing environments
• Reconciling a rewritten migration history with live databases

Not for

• Squashing migrations that never applied anywhere (safe; just do it)
• A squash that only renamed files without changing ids (harmless)
• Fresh environments failing to bootstrap (restore the files)

Steps

1. Map the old chain to the new squash

List the old revision ids production recorded and the new squash revision that replaces them. Read both: the squash's upgrade must produce exactly the schema the old chain produced.

Expected output: a mapping of old ids to the new squash id, and a statement of what each side builds.

2. Prove schema equivalence on scratch databases

Build one scratch database with the old chain and one with the squash, then diff the schemas (pg_dump --schema-only on both, diffed, or your database's equivalent). Expected output: no differences. If there are differences, the squash is wrong: fix the squash, not production.

3. Option A (safest): keep the old files alongside the squash

Restore the old files and keep them until every environment (prod, staging, every developer database) has migrated past the squash point. New environments use the squash; old environments walk the old chain once, then continue from the squash. Expected output: no environment ever sees a missing id, because no id it recorded disappears.

4. Option B: stamp production to the new base

Only after step 2 proves equivalence: on production, stamp the state to the squash revision so its recorded history matches the new files. Rehearse on a restored copy of production first.

alembic stamp [squash revision]

Expected output: production's state table references only ids that exist in the new files. This is a point of no return: the old chain must never be needed again.

5. Set the squash rule for agents

Agents may only squash migrations that have never applied outside the agent's own scratch database. Anything applied anywhere is immutable history.

Expected output: the next squash proposal starts with "has this applied anywhere", and the answer gates the whole operation.

Tool compatibility

Written for alembic (revision ids, stamp); the principle is identical for django squashes, rails, and flyway: never rewrite applied history.

Variant phrasings

agent squashed migrations production still runs old files

Steps 1 through 3: map, prove equivalence, keep old files until every environment passes the squash point.

squash migrations already applied in production

Step 4 only after proving equivalence on scratch: stamp production to the new base.

alembic squash broke production history

Step 3 is the recovery: restore the old files. The squash can wait; production's history cannot be missing.

Why it happens

Migration history is a contract between the files and every database that recorded them. Squashing rewrites the files' side of the contract while production still holds the old side, so commands that join the two (history, upgrade, heads) break. The schema may be identical; the disagreement is purely about identity, which is why proving equivalence is the key step.

Edge cases

• Stamping production to the squash is irreversible in practice: keep the old files in version control forever, even after stamping, as documentation.
• Developer databases are environments too: "everywhere" includes laptops, or the next fresh checkout breaks.
• If the squash changed any semantics (not just collapsed), it is not a squash but a rewrite: treat it as a new migration chain and migrate data explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WffkIMFm1zI0QkPJAjgncQ