MigrationFailedException thrown during partial rollback of a custom change in Liquibase

The goal is to clarify how Liquibase sequences custom changes—particularly Java code changesets and SQL changesets—when a rollback is interrupted before completion, and whether the thrown MigrationFailedException indicates which changeset was partially rolled back.

Because the framework does not explicitly document the ordering rule for mixed change types, the execution order may be ambiguous, and a partial rollback can leave the database in an inconsistent state, especially given potential differences between the open‑source and Pro editions and across version lines.

Key questions: How does Liquibase decide the execution order of a Java custom change relative to preceding SQL changesets? Does MigrationFailedException expose the specific changeset that experienced a partial rollback, and can any automatic compensation be triggered? Is this behavior stable between Liquibase 4.9.x and 5.x releases?