Checksum mismatch with different relative path in 6.0.

[esauser]

Which version and edition of Flyway are you using?

6.0.3

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)

Command-line

Which database are you using (type & version)?

SQL Server 2017 CU 16 Docker

Which operating system are you using?

Alpine Linux

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.)
Upgraded from 5.2.4 and ran migrate.

What did you expect to see?

Migrate successfully

What did you see instead?

Checksum mismatch.

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.

[esauser]

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?

[MikielAgutu]

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.

[esauser]

We figured out what's happening here. All of the migrations that have a mismatching checksum have a BOM. If we remove the BOM, the checksum matches. Thus, a change was introduced that includes the BOM in the checksum whereas before it was not included.

[esauser]

@MikielAgutu actual steps to reproduce the issue:

1. Apply migration containing BOM with 5.2.4
2. Run flyway validate with 6.0.3 and observe checksum mismatch on said file

[MikielAgutu]

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.

[esauser]

@MikielAgutu when do you expect to release 6.0.4?

[MikielAgutu]

We'll probably release next week - we aim to have a fairly frequent cadence for patch versions.