liquibase: Using 4.23.0, my app fails to start because of invalid checksums

Search first

I searched and no similar issues were found

Description

Our application (Java/Spring/MySQL) is currently using 4.20.0 and works fine. When I upgrade to 4.23.0, it fails to start due to Liquibase failing due to invalid checksums.

	Caused by: liquibase.exception.CommandExecutionException: liquibase.exception.ValidationFailedException: Validation Failed:
     1 changesets check sum
          org/foo/db/phase5/foo-bar-2017-09-14.xml::DECREASE_FP_FIELD_FOR_PDP::jdoe was: 8:83871094f06fbeba7a3755bb6e7980c0 but is now: 8:7afe9a1d89ce253fbca2d513dcdc2834

Steps To Reproduce

The offending changeset (names changed to protect the innocent):

    <changeSet author="jdoe" id="DECREASE_FP_FIELD_FOR_PDP" context="bootstrap,demo,unit">
        <comment>Words words words. Please review if your institution would like this change. See JIRA-123 for details.</comment>

        <sql dbms="mysql">
            update FP_DV_PAYEE_DTL_T A join FP_DV_PAYEE_DTL_T B ON A.FDOC_NBR = B.FDOC_NBR set A.DV_RMT_PRSN_NM = SUBSTR(B.DV_RMT_PRSN_NM,1,75);
        </sql>

        <sql dbms="oracle">
            update FP_DV_PAYEE_DTL_T A set DV_RMT_PRSN_NM = (select SUBSTR(DV_RMT_PRSN_NM,1,75) from FP_DV_PAYEE_DTL_T B where A.FDOC_NBR = B.FDOC_NBR);
        </sql>

        <modifyDataType columnName="DV_RMT_PRSN_NM" newDataType="VARCHAR(75)" tableName="FP_DV_PAYEE_DTL_T"/>
    </changeSet>

Expected/Desired Behavior

My app would startup like it does with 4.20.0.

Liquibase Version

4.23.0

Database Vendor & Version

MySQL 5.7

Liquibase Integration

Spring (not Boot)

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

macOS

Additional Context

No response

Are you willing to submit a PR?

I’m willing to submit a PR (Thank you!)

About this issue

Original URL
State: closed
Created a year ago
Comments: 15 (7 by maintainers)

Most upvoted comments

Thank you for the quick response @filipelautert. I can confirm that with version DAT-16006-SNAPSHOT the error doesn’t occur.

Alf-Melmac on Oct 2, 2023

@jbisotti it was really confusing. So:

4.21.1 must be fine for you now
Don’t upgrade to 4.23.0 because of this bug
Once PR https://github.com/liquibase/liquibase/pull/4453 is merged you can upgrade (probably 4.23.1 or 4.24.0) .

filipelautert on Jul 5, 2023

This issue was not fixed in version 4.32.1 (where the mentioned pr https://github.com/liquibase/liquibase/pull/4453 was merged into). This can be reproduced if you create a changeset where the dbms of the sql statement doesn’t match your current database. For example in an environment with postgres

<changeSet id="broken.a" author="test">
	<sql dbms="!postgresql">
		-- Some SQL
	</sql>
</changeSet>

<changeSet id="broken.b" author="test">
	<sql dbms="mssql">
		-- Some SQL
	</sql>
</changeSet>

Use liquibase version 4.21.1 and execute mvn liquibase:update. Afterwards update to the current version 4.23.2. I’ve created a minimal reproducible example: https://github.com/Alf-Melmac/liquibase-issue-checksums with some more examples in the changelog.xml

Alf-Melmac on Sep 25, 2023

We have same problem but it gets new md5sum every time we run update-testing-rollback.

It only happens on changesets where we are using parameters in liquibase.properties file.

Will this be resolved by same fix or should I create new issue?

Edit: Looks like it is more related to https://github.com/liquibase/liquibase/issues/4451

jacokok on Jul 4, 2023

Hello @jbisotti - I saw you’re using 2 dbms tags within the same changeset so your problem is related to the 4.23.0 bug that will be fixed by PR https://github.com/liquibase/liquibase/pull/4453 . Meanwhile there are 3 workarounds to upgrade:

add tag<validCheckSum>1:any</validCheckSum>to your changeset, upgrade to 4.23.0 then remove it.
run clearChecksums command and then upgrade.
Update db changelog table using the new checksum: update databasechangelog set md5sum = '8:7afe9a1d89ce253fbca2d513dcdc2834' where md5sum = '8:83871094f06fbeba7a3755bb6e7980c0' .

filipelautert on Jul 3, 2023

@filipelautert - passing this along to you since it’s likely related to the 4.23.0 checksum change

kevin-atx on Jun 30, 2023