agent applied 12 of 30 flyway migrations then crashed - flyway_schema_history disagrees with what the agent remembers

TL;DR: flywayschemahistory is the source of truth - the agent's memory of the run is not. Query the history table ordered by installed_rank, check the success column, and run flyway info to see the pending set. Repair any failed row, then re-run flyway migrate: it resumes where it stopped and never re-applies a successful migration.

The problem as reported:

agent applied 12 of 30 flyway migrations then crashed - flyway_schema_history disagrees with what the agent remembers

1. Read the history table: select version, description, success, installed_on from flyway_schema_history order by installed_rank;. Expected: 12 rows with success true, and possibly one trailing row with success false if the crash landed mid-migration.
2. Run flyway info. Expected: the succeeded versions show Success, the rest show Pending.
3. If a row shows success false: figure out what that migration did, manually finish or undo its partial effects in the database, then run flyway repair. Expected: flyway info shows that version as Pending again instead of Failed.
4. Do not edit any migration file that already applied - the checksum column will mismatch and flyway will refuse to run anything. A change to applied SQL is a new migration, full stop.
5. Run flyway migrate. Expected: applies only the pending versions in order and ends with a success message naming the count applied.
6. Verify: re-run the query from step 1. Expected: all 30 rows present with success true.

Use this when

• A flyway run was interrupted by a crash, kill, or lost connection.
• The agent's notes about progress conflict with the history table.
• A migration row is stuck in failed state.

Not for this skill when

• The history table itself is missing or corrupt - that's a baseline/repair scenario, not a resume.
• You're using a different migration tool - each has its own state table and resume command.

Variant phrasings

• flyway crashed mid migrate how to resume
• flywayschemahistory success false after crash
• flyway re-run after crash skips applied migrations
• flyway repair failed migration row

Why it happens

Flyway writes each migration's outcome into the history table as it goes, so the table reflects what the database actually did. The agent's in-memory notes reflect what it hoped to do - after a crash those two disagree, and the table wins.

Edge cases

• Version 13 half-applied its DDL before crashing: flyway can't roll back DDL on most databases, so repair the row only after manually reconciling the schema.
• Out-of-order migrations with outOfOrder enabled: installed_rank, not version order, is the application order - read that column.
• Another instance is migrating the same database concurrently: coordinate first; two writers will deadlock or interleave versions.

Provenance

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