Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Checksum mismatch with different relative path in 6.0. #2503
Which version and edition of Flyway are you using?
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)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Which database are you using (type & version)?
SQL Server 2017 CU 16 Docker
Which operating system are you using?
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.)
What did you expect to see?
What did you see instead?
It appears the checksum formula changed between 5.2.4 and 6.0.3. We are running flyway against docker images locally and in a deployment pipeline. The relative paths of the migrations change throughout this process. It seems that the checksum formula now takes the relative path into account which breaks out process.
You can reproduce this by applying a migration to a database with 5.2.4, then moving the migration to a new relative path and running validate with 6.0.3 against the same database; the checksum will not match. If you move the same migration and run validate with 5.2.4 it does not fail.
Note that this applies to both versioned and repeatable migrations.
There is more to this. There are also a handful of migrations that don't change paths that are reporting a different checksum. 5.2.4 is fine, but 6.0.3 reports a mismatch. Exactly, what change changed with the checksum calculation? Was it intentional? Can it be reverted?
Checksum problems can occur when migration scripts are unintentionally changed. Line ending changes are a common cause, since things like git can change them without making it obvious. See #2474 for example.
As far as I can see we only use the migration contents to generate the checksum. The logic been refactored between 5.2.4 and 6.0.3, so I suppose it's possible there is a bug here.
However I've followed your reproduction steps and have been unable to reproduce the issue. I suggest checking to make sure your scripts aren't being altered by your deployment process. For instance can you compare the scripts at each stage of your process before and after the relative paths change? Can you also send over the scripts which are causing issues so we can further investigate on our end.
Ok, with the new steps I've managed to reproduce this. We're working on a fix, although you'll probably need to Repair as a workaround in the meantime.
The fix will ignore BOMs going forward, so if possible you should manually amend your files to remove the BOMs so you don't need to repair again when the fix is released - unless you don't mind doing another ad-hoc Repair. Or I suppose you can continue using 5.2.4. Sorry for inconvenience that causes.