Undo command does not respect the expected order when used with target

[quentinbricard]

What version of Flyway are you using?

5.0.3 trial pro version

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API + Gradle plugin

What database are you using (type & version)?

PostgreSQL 9.6

What operating system are you using?

macOS SIERRA 10.12.6

What did you do?

(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
I have the following scripts:

• V1__create_schema.sql
• V2__add_table2.sql
• U3__add_table2.sql
• V3__add_table3sql
• U3__add_table3.sql
• V4__add_table4.sql
• U4__add_table4.sql
  With all V_X___add_table_X_.sql scripts creating a new table called table_X_
  And all U_X___add_table_X_.sql scripts droping the table called table_X_

I first migrated my database to be on current version 4, with my initial schema and all table2, table3, and table4 created.

I launched flyway.undo() providing the property flyway.target with value 3.

What did you expect to see?

I expected to see that U4__add_table4.sql got executed

What did you see instead?

I saw no undo migration executed at all.
Instead, I saw this message:
Schema "_mySchema_" has no migrations to undo.

Digging in the bytecode, I can say my issue is located in this block (class DbUndo):

if (undoCandidate.getVersion() != null && !undoCandidate.getType().isSynthetic() && !undoCandidate.getType().isUndo() && undoCandidate.getState() != MigrationState.UNDONE) {
                    if (this.configuration.getTarget() != null && this.configuration.getTarget().compareTo(undoCandidate.getVersion()) > 0) {
                        break;
                    }

                    undoCandidates.add(undoCandidate);
                }

When iterating with element V2__add_table2.sql, we have this statement:
this.configuration.getTarget() which is 3, compared to:
undoCandidate.getVersion() which is 2.
So, we break the iteration before actually executing any undo migration.

[axelfontaine]

Good catch and thanks for the investigation. Consider this fixed in the next release. Until then you should be able to work around this by not using target.

[axelfontaine]

This has now been fixed. Thanks again for the analysis. That was very helpful in pinpointing and reproducing this quickly.