Bug in v4.21+ changesets are not run because AbstractUpdateCommandStep.isUpToDateFastCheck incorrectly caches value across schemas

General Discussion
1

Steps to reproduce:

  • configure liquibase with at least one changeset
  • call liquibase = liquibaseFactory.createLiquibase(schemaName); liquibase.update("default") with a schema that is up-to-date (i.e., has no changesets to apply)
  • create a second schema
  • call liquibase = liquibaseFactory.createLiquibase(schemaName2); liquibase.update("default")
    Expected behavior:
    liquibase updates the second schema with the configured changesets
    Actual behavior:
    liquibase does not update the second schema

The problem is that the first call to AbstractUpdateCommandStep.isUpToDateFastCheck is setting the entry for “default/()” in the upToDateFastCheck map to true (indicating no un-run changesets). That entry will never be changed, even for a different schema, so all subsequent calls to isUpToDateFastCheck will return true, and no changesets will be run.

This seems similar to the problem in v4.22.0 but I don’t know if it’s actually the same problem in a different guise.

2

Just ran across the same issue while debugging why my Liquibase claimed my change logs were executed even though they clearly were not!
The cacheKey should also contain the database url and databasechangelog, not just contexts and labelexpressions.

3

@jglass and @Hylke - there have been a series of updates to Liquibase recently that address checksum issues. Please try Liquibase 4.23.0 or later to see if that addresses your issue.

Note: the upcoming Liquibase 4.23.1 release (on track for a mid-August) handles a few more checksum-related edge cases if the 4.23.0 release doesn’t fully resolve the issues you’re currently experiencing.

4

I’m using 4.23.0. It does not correctly calculate the cacheKey, and stores it in a static map, breaking subsequent runs.

5

I have verified that the problem is fixed in the 4.25.0 release.