Checksum Mismatch Errors When Running Concurrent Pipeline Jobs

Summary

After upgrading Liquibase Secure (formerly Liquibase Pro), customers running multiple deployment pipelines close together in time (within seconds of one another) against the same database may see Liquibase report checksum mismatches and attempt to redeploy changesets that were already successfully applied. This is caused by a caching issue during the internal checksum migration and is fixed in Liquibase Secure 5.2.1.

Applies To

• Liquibase Secure (Pro) — versions 4.23.0 to 5.2.1
• Any target database
• Environments that run two or more Liquibase update jobs concurrently (or in very quick succession) against the same changelog/database, particularly right after an upgrade

Symptoms

• Two pipeline/deployment jobs are triggered close together, sometimes only seconds apart.
  • The first job completes successfully and applies its changesets as expected.
  • The second job, instead of only processing its own new changesets, scans the full changelog, including changesets that have already run, and attempts to reapply changes already present in the target database.
• This second run fails with a checksum error, even though the affected changeset files were not modified.
• The issue is intermittent and tends to appear only when jobs overlap; sequential (non-concurrent) runs against the same changelog do not show the problem.

Cause

Liquibase tracks each changeset's checksum in the DATABASECHANGELOG table so it can detect whether a previously-run changeset has changed. When two update jobs run concurrently against the same changelog, the following race condition can occur:

1. The first job begins updating checksums in the DATABASECHANGELOG as part of an internal checksum format migration.
2. The second job starts within seconds of the first and reads/caches checksum values from DATABASECHANGELOG while the first job's update is still in progress (i.e., only partially written).
3. The second job then waits on the changelog lock and resumes once the first job releases it.
4. Because the second job is working from partially updated (stale) checksums it cached earlier, when it recalculates and compares checksums, it finds mismatches that don't actually reflect any real change in the changeset.

This is most likely to surface immediately after an upgrade, when Liquibase is migrating stored checksums to a newer checksum format and two jobs are launched close enough together that the second starts before the first has finished writing its checksum updates.

Resolution

This issue is fixed in Liquibase Secure 5.2.1 (listed in the release notes as SECURE-288). The fix ensures checksum values are cached and validated correctly when multiple deployments run concurrently, eliminating the race condition described above.

We recommend upgrading to 5.2.1 or later to permanently resolve this issue.

Note: As of Liquibase Secure 5.0+, Liquibase Pro has been renamed to Liquibase Secure, and there are a few packaging changes to be aware of when upgrading. For details, see: New Distribution Channels for Liquibase Secure 5.0

Workaround (If you can't upgrade right away)

If you're not yet able to upgrade to 5.2.1, you can avoid triggering this issue by preventing concurrent deployments during the window when checksums are being migrated:

• After upgrading to a new Liquibase version, run one Liquibase update to completion before allowing any other pipeline to run against the same changelog/database. This allows Liquibase to complete migrating its stored checksums before a second job can read them mid-update.
• Avoid scheduling or triggering multiple pipelines that target the same changelog/database at the same time (or within moments of each other) until you've upgraded to 5.2.1 or later.

This workaround reduces the risk of hitting the race condition, but upgrading to 5.2.1+ is the permanent fix.