Liquibase re-running old migrations after update

[Poundex]

Search first

• I searched and no similar issues were found

Description

Hello,

After updating Liquibase (from 3.10.2) we are finding that our migrations are now failing as Liquibase is attempting to re-run old migrations again. Observed this behaviour in 4.25.1 and 4.27.

This looks similar to both #5607 (but we are not using classpath:) and #5724 (but we are not using any unnormalised relative paths).

Our entire changelog is simply this:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
         http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">

    <includeAll path="migrations"/>
</databaseChangeLog>

The migrations do not start again from the beginning, but instead from version 6. When the migration is ran the database is at v18 and there should be only one migration that runs to take it to v19.

From what I can see it's because the old version of Liquibase used different tags/markers as part of the migration name than new Liquibase is, and in failing to find an exact match Liquibase decides the migration has never ran and tries to run it again:

The ":class-management" marker is what has always been in the SQL file, and the "raw" and "includeAll" are what old Liquibase had stored in the change log table:

where "raw" and "includeAll" are used as id/author.

Steps To Reproduce

As above

Expected/Desired Behavior

Does not run migrations that have already ran

Liquibase Version

No response

Database Vendor & Version

Postgres 15

Liquibase Integration

DropWizard

Liquibase Extensions

No response

OS and/or Infrastructure Type/Provider

No response

Additional Context

No response

Are you willing to submit a PR?

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

[tati-qalified]

Hi @Poundex, thank you for reporting this issue.

I can confirm that this is a problem, and it's most likely caused by the filepath processing - for 3.10.2, the filename is stored as <absolutePath>/migrations/filename, while for 4.25.0 and 4.27.0 it's stored as `migrations/filename'.

There is a fix for this problem already merged to the master branch, but not yet released as a new version. Would you be able to test this using a snapshot of the master branch?

You can download it from here: https://github.com/liquibase/liquibase/actions/runs/8879724558/artifacts/1456919577 or obtain it using GPM (gradle or maven ):

<dependency>
 <groupId>org.liquibase</groupId>
 <artifactId>liquibase-core</artifactId>
 <version>master-SNAPSHOT</version>
</dependency>

api("org.liquibase:liquibase-core:master-SNAPSHOT")

Let me know if it works for you or not.
Thank you,
Tatiana

[Poundex]

Thanks for the update, @tati-qalified
I have tried this snapshot this morning but am seeing the same results. It seems Liquibase is still comparing the "raw/includeAll" (from the changelog in the DB) with "6/class-management" (from the changefile itself) and trying to run the migration again.

[tati-qalified]

Have you tried with a lower version, for example 4.6.0? Please check and let me know if the problem persists.

Apart from that, could you provide the code for one or two of changesets that are being re-run?

Thank you