Regression Issue: Checksums invalid for blank migrations applied in v5.0.7 and below

[cdavid15]

Which version and edition of Flyway are you using?

5.1.1 Community
5.1.3 Community

If this is not the latest version, can you reproduce the issue with the latest one as well?

(Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Yes it is on latest. Linked to #2027?

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

Commands Line

Which database are you using (type & version)?

Oracle 12c / H2 although issue is applicable to all

Which operating system are you using?

Windows 10 v1703

What did you do?

(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

• Ensure flyway-5.0.7 is on the PATH
• Create a new folder
• Create a blank file versioned migration (ie V1.0.0__BLANK_FILE.sql)
• Execute the following:

flyway -url=jdbc:h2:file:./regressiondb  -user=SA  -password=  -locations=filesystem:./SQL info
flyway -url=jdbc:h2:file:./regressiondb  -user=SA  -password=  -locations=filesystem:./SQL migrate
flyway -url=jdbc:h2:file:./regressiondb  -user=SA  -password=  -locations=filesystem:./SQL validate

• Update the PATH to point to flyway-5.1.1 SET PATH=C:\Utils\flyway-5.1.1;%PATH%

• Verify version has changed to 5.1.1
  *Execute a validate

  • flyway -url=jdbc:h2:file:./regressiondb -user=SA -password= -locations=filesystem:./SQL validate

• Update the PATH to point to flyway-5.1.3 SET PATH=C:\Utils\flyway-5.1.3;%PATH%

• Verify version has changed to 5.1.3
  *Execute a validate

  • flyway -url=jdbc:h2:file:./regressiondb -user=SA -password= -locations=filesystem:./SQL validate

What did you expect to see?

Database: jdbc:h2:file:./regressiondb (H2 1.4)
Successfully validated 1 migration (execution time 00:00.028s)

What did you see instead?

Database: jdbc:h2:file:./regressiondb (H2 1.4)
ERROR: Validate failed: Migration checksum mismatch for migration version 1.0.0
-> Applied to database : 0
-> Resolved locally : 1702646501

[cdavid15]

You may wonder why a blank migration file. It was essentially for display purposed when running info commands to indicate the start of a release.

For example, the application was version 4.0.0 and while developing we automatically started on release candidate 1 so the first script would be 4.0.0.1.1.

If it was RC 10 then it would have been 4.0.0.10.1.

The blank files were used to create a migration which indicated the type of release:

• V4.0.0.1__~~~~~~~ RELEASE CANDIDATE ~~~~~~~.sql
  • Versioned scripts were in the format V4.0.0.1.XX__[ISSUE#]_DESCRIPTION.sql
• V4.0.0.10__~~~~~~~ RELEASE CANDIDATE ~~~~~~~.sql
  • Versioned scripts were in the format V4.0.0.10.XX__[ISSUE#]_DESCRIPTION.sql

We have now ceased this approach in favour of a timestamp based variation to work with feature branching however these migrations have already been applied across a number of database environments so will have to stay of version 5.0.7 until this regression issue is fixed.

[axelfontaine]

Thanks for reporting. Arrghh! We definitely didn't test this edge case. And indeed we had an issue in our UTF BOM stripping that didn't account for it. Fixed.