agent ran flyway 10 commands against a flyway 9 schema history table - the checksums dont match anymore

TL;DR: Do not mix Flyway majors against one history table - major versions can compute checksums differently. Pick one major for the whole project, pin every runner to it, and run flyway repair once to recalculate the stored checksums under the chosen version. Then verify the history table is consistent.

agent ran flyway 10 commands against a flyway 9 schema history table - the checksums dont match anymore

1. Confirm the skew. Check which Flyway version wrote the history rows and which version is validating them now.

flyway --version
SELECT version, checksum, installed_by, installed_on FROM flyway_schema_history ORDER BY installed_rank DESC LIMIT 5;

Expected: the CLI reports a different major (10) than the one the team standardized on (9), and validate/migrate fails on checksum mismatch for unchanged files.

2. Decide the project's single major version deliberately. Either the project moves to 10 together, or the runner goes back to 9. There is no supported mixed mode.

Expected: one version named as the standard, agreed rather than accidental.

3. Pin every runner to that version: developer machines, CI images, and agent sandboxes. Uninstall or de-prioritize the other major on PATH.

Expected: flyway --version reports the standard major everywhere it runs.

4. If the project is moving to the new major, realign the stored checksums once.

flyway repair

Expected: repair recalculates the checksums under the new version's algorithm and reports success. Failed rows get cleaned up as part of the same repair.

5. Run flyway validate and then migrate, and confirm the history table is consistent and green.

Expected: validate passes, migrate reports everything up to date, and the checksums in the table match what the pinned CLI computes.

Use this when

• Flyway reports checksum mismatches after a CLI version change
• flyway 10 commands ran against a flyway 9 history table (or any major-version mix)
• Unchanged migration files suddenly fail validation
• You need to standardize the team on one Flyway major

Not for this skill when

• The checksum mismatch is because someone edited an already-applied migration file - that is a process violation; repair is not the fix, reverting the edit is
• Only the minor or patch version changed - those do not change the checksum algorithm; look for file edits instead
• The history table itself is corrupt or missing rows - that needs history surgery, not a repair
• You want different majors for different environments - standardize instead; mixed majors are unsupported

Variant phrasings

• flyway checksum mismatch after upgrade to 10
• flyway 10 vs 9 schema history checksums dont match
• flyway validate fails checksum after CLI update
• how to fix flyway checksum validation failure new version

Why it happens

Flyway validates applied migrations by recomputing each file's checksum and comparing it to the value stored when the migration first ran. Major versions can change how that checksum is computed, so a file that validated under 9 fails under 10 even though nobody touched it. The check is doing its job - detecting that the verifier changed - but the fix is to make the verifier consistent, not to fight the check per file.

Edge cases

• repair also removes failed-version rows and fixes other history inconsistencies. Review what it plans to change before running it on a shared database.
• If some environments already migrated under the new major and others under the old, pick the version the production history table was written with and realign everything else to it.
• Editing a migration file after it applied will still fail validation after a repair - repair realigns the algorithm, it does not bless edited files.
• Agent sandboxes with a floating latest install are the usual source of surprise majors. Pin the version in the sandbox setup, not just in docs.

Provenance

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