ShouldRunChangeSetFilter initialization behavior update from 3.5.0 breaks custom task

Description

Context

We have a product that extends and customizes a base application provided by a third party. The base application has its own set of ChangeSet and we add our own ChangeSet as well. We sometime need to prevent a ChangeSet from being executed on our database (as an example: an index is added in the base application that we already added in a previous version).
To perform that task we developped a CustomTaskChange named MarkAnotherChangeSetAsExecuted. See attached MarkAnotherChangeSetAsExecuted class and 5.0.1-changelog.xml for a call example.

We recently upgraded to liquibase 3.5.3 from a much older 3.0.8 and we started seeing excluded ChangeSet being executed despite being marked as executed in the database.

Problem description

Commit a272d9ffd6a796237fad1465ed13cd726a3be617 introduced a change in behavior of ShouldRunChangeSetFilter. Prior to the change the filter was always in synch with Database.getRanChangeSetList() so any ChangeSet added at runtime would be available to the filter.
After the commit only a snapshot of the ChangeSet present in DatabasegetRanChangeSetList() at initialization time is available to the filter.
Since MarkAnotherChangeSetAsExecuted adds ChangeSet in Database at runtime those are ignored by ShouldRunChangeSetFilter and the excluded ChangeSet ends up being executed against our will.

Proposed solution

Revert ShouldRunChangeSetFilter initialization to use actual Database.getRanChangeSetList() and update ShouldRunChangeSetFilter.accept() logic to filter the list for the latest executed ChangeSet instead.

Environment

Any database, any OS, Liquibase 3.5.0+

Status

Assignee

Unassigned

Reporter

Christian Arcand

Labels

None

Fix versions

Priority

Blocker
Configure