agent retried a failed migration without checking state first - the retry applied the same DDL twice and corrupted...

TL;DR

Stop and inspect before retrying anything. Query the tool's migration history table to see which revisions actually landed, then repair or mark the landed ones before re-running. Retrying blindly replays DDL that already succeeded, and DDL usually cannot be rolled back, so the retry compounds the damage instead of fixing it.

agent retried a failed migration without checking state first - the retry applied the same DDL twice and corrupted the schema

Steps

1. Do not run the migration again yet. A second blind run is how the corruption got worse the first time. Expected: no new migration process is running while you investigate.

2. Read the migration history table for the tool you use. Alembic: select version_num from alembic_version;. Django: select migration from django_migrations order by applied;. Flyway: select version, success from flyway_schema_history order by installed_rank;. Prisma: select migration_name, finished_at from _prisma_migrations order by started_at;. Expected: a list of recorded revisions with timestamps, so you can see exactly where the failed run stopped.

3. Compare the history table against reality. For the failing revision, check whether its DDL partially landed, for example select column_name from information_schema.columns where table_name = '[table]';. Expected: you know precisely which objects exist and which are missing.

4. Reconcile state before re-running. If DDL landed but the history row is missing or marked failed, record it: Alembic alembic stamp [revision]; Flyway flyway repair; Prisma prisma migrate resolve --applied "[name]". If the DDL did not land, mark it rolled back instead (Flyway repair, Prisma --rolled-back). Expected: the history table matches the real schema, and the tool's validate/info command reports no mismatch.

5. Re-run the migration now. Expected: it completes cleanly, and the history table shows the new revision as applied.

Use this when

• A retry duplicated DDL (duplicate column, duplicate index, duplicate constraint errors).
• The schema looks half-migrated and nobody knows which half.
• The history table disagrees with what is actually in the database.
• An agent is about to retry a failed migration and has not checked state first.

Not for this skill when

• The migration never ran at all (nothing to reconcile, just run it).
• Two agents wrote to the database at the same time (that is a concurrency problem, not a retry problem).
• Application data is duplicated but the schema itself is fine.

Variant phrasings

• migration retried twice and now the schema is corrupt
• DDL applied twice by the same migration
• how to check which alembic revisions applied before retrying
• flyway re-applied a migration that already ran

Why it happens

Migration tools record progress in a history table, but a failed run can apply some DDL before the error while leaving the history row unmarked or marked failed. The retry then replays the same DDL against an already-changed schema. Most DDL is not transactional in the way agents expect (and some, like concurrent index builds, cannot run inside a transaction at all), so there is no automatic rollback to save you.

Edge cases

• If the DDL destroyed something (dropped a column), no amount of history repair brings it back. Restore from backup first, then reconcile.
• When the old and new states are both partially present, do not re-run the original file. Write a small one-off repair migration that converges the schema to the intended end state.
• Alembic stamp is a lie you tell the tool on purpose. Only use it after verifying the schema really matches the stamped revision.

Provenance

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