MigrationFailedException thrown during partial rollback of a custom change in Liquibase

Execution Order and Rollback Logic

Liquibase executes changesets in the exact order they appear in the changelog file, regardless of whether the change is a standard SQL statement or a custom Java implementation. During a rollback, Liquibase processes these changesets in reverse chronological order based on their execution sequence.

Custom Java Changes vs. SQL Changesets

If a custom Java changeset follows several SQL changesets in the changelog, the Java changeset will be the first to be rolled back. The framework does not prioritize change types; it strictly follows the stack (Last-In, First-Out) for rollbacks. If the custom Java rollback logic fails, the process halts immediately, and any preceding SQL changesets (which were deployed earlier) will remain in the database.

Analyzing MigrationFailedException

The MigrationFailedException is a generic wrapper. It does not inherently contain a dedicated field explicitly naming the "partially rolled back" changeset. Instead, you must rely on two primary diagnostic sources:

• The Stack Trace: For custom Java changes, the underlying cause (the inner exception) will typically point to the specific Java class and method where the failure occurred.
• The DATABASECHANGELOG Table: Because Liquibase updates the tracking table as it progresses, the state of this table indicates which changesets were successfully reverted and which remain marked as deployed.

Automatic Compensation

Liquibase does not provide automatic compensation for partial rollbacks. If a rollback fails, the database state depends entirely on the transactionality of your underlying database engine. If the database supports DDL transactions (e.g., PostgreSQL), the failed rollback may be atomic. If it does not (e.g., MySQL), you may be left in an inconsistent state requiring manual intervention.

Version Stability and Verification

The core sequencing logic—sequential execution and reverse rollback—is a fundamental architectural behavior and remains stable between Liquibase 4.9.x and 5.x. Differences between Open Source and Pro editions generally apply to deployment tooling and snapshots, not the execution order of mixed change types.

Verification Steps

To identify the point of failure and verify state, use the following scoped approach:

1. Query the changelog table:

   SELECT id, author, filename FROM DATABASECHANGELOG ORDER BY dateexecuted DESC;

   Identify the most recent changeset that was not removed during the rollback attempt.
2. Isolate the failure: Create a minimal reproduction changelog containing one SQL changeset followed by one custom Java changeset to confirm the reverse-order behavior in your specific environment.

Required Diagnostic: To provide a more specific recovery path, please clarify if your database engine supports transactional DDL (e.g., PostgreSQL) or if it commits DDL changes immediately (e.g., MySQL/Oracle).