Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checksum mismatch with different relative path in 6.0. #2503

Closed
esauser opened this issue Sep 13, 2019 · 7 comments
Closed

Checksum mismatch with different relative path in 6.0. #2503

esauser opened this issue Sep 13, 2019 · 7 comments
Labels
Milestone

Comments

@esauser
Copy link

@esauser esauser commented Sep 13, 2019

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

This comment has been minimized.

Copy link
Author

@esauser esauser commented Sep 13, 2019

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

This comment has been minimized.

Copy link
Member

@MikielAgutu MikielAgutu commented Sep 16, 2019

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.

@MikielAgutu MikielAgutu added the t: bug label Sep 16, 2019
@esauser

This comment has been minimized.

Copy link
Author

@esauser esauser commented Sep 16, 2019

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

This comment has been minimized.

Copy link
Author

@esauser esauser commented Sep 16, 2019

@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

This comment has been minimized.

Copy link
Member

@MikielAgutu MikielAgutu commented Sep 17, 2019

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.

@MikielAgutu MikielAgutu added this to the Flyway 6.0.4 milestone Sep 17, 2019
@esauser

This comment has been minimized.

Copy link
Author

@esauser esauser commented Sep 17, 2019

@MikielAgutu when do you expect to release 6.0.4?

@MikielAgutu

This comment has been minimized.

Copy link
Member

@MikielAgutu MikielAgutu commented Sep 18, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.