Migrating to Liquibase 3.8, Liquibase tries to execute all the already ran ChangeSets whose runOnChange attribute is set to true.

Description

StandardChangeLogHistoryService: invalid databaseChecksumsCompatible at run(UpdateVisitor) step

Migrating from Liquibase 3.5.2 to Liquibase 3.8.1, we ran into an issue:

Liquibase tries to execute all the already ran ChangeSets whose runOnChange attribute is set to true.

I investigated and found that in the StandardChangeLogHistoryService, the databaseChecksumsCompatible field is set to false in the init() method, because the CheckSum version is 7 instead of 8, and then updates all the md5sums to NULL, so they get upgraded at a later step.

LogExtract:

On every UPDATE query, method reset() is called to mark the service as uninitialized and empty the ranChangeSetList.

Once the new CheckSums are generated and stored in DB, the databaseChecksumsCompatible field is never set to true, therefore when the ranChangeSetList is recreated, at line 317, the md5sum is set to null even though the md5sum in the result set is valid.

Later, the ShouldRunChangeSetFilter.checksumChanged() method returns true and Liquibase tries to run the already ran ChangeSet.

LogExtract:

Workaround

As the checksum updates are not rolled back, re-invoking liquibase works perfectly.

Questions

If the service is marked as uninitialized, should the init() method be called again somewhere?
Should the databaseChecksumsCompatible field be set to true after the upgradeChecksums() method is ran?

Thanks.

Environment

OpenJDK8, migrating from CheckSum version 7 to CheckSum version 8.

Status

Reporter

Jonathan Bayle

Components

Affects versions

Priority

Major
Configure