JDBC Migration failures not entered into schema_version table

[cmcmurtrie]

Which version and edition of Flyway are you using?

4.2.0 - also exists on 5.0.6

If this is not the latest version, can you reproduce the issue with the latest one as well?

(Many bugs are fixed in newer releases and upgrading will often resolve the issue)

yes

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

Gradle

Which database are you using (type & version)?

mysql 5.6

Which operating system are you using?

osx

What did you do?

(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

Failed jdbc migration

What did you expect to see?

When a jdbc migration fails, I expect to see the failed migration entered into the schema_version table and marked as failed.

What did you see instead?

The failed jdbc migration is never entered into the schema_version table.
This did not occur in version 3.0. It looks like there was a change to the exception catching in the DBMigration.applyMigrations method. Version 3.0 caught all FlywayExceptions and updated the metaDataTable whereas Version 4.2.0 and later only catch FlywayMigrateSqlExceptions. When the type is JDBC, the exception is thrown but not caught and so the metaDataTable never updated. I didn't see any added customization options to handle this and ensure that these failures are inserted into the table.

[cmcmurtrie]

version 3

    } catch (FlywayException e) {
        String failedMsg = "Migration of schema " + schema + " to version " + version + " failed!";
        if (dbSupport.supportsDdlTransactions()) {
            LOG.error(failedMsg + " Changes successfully rolled back.");
        } else {
            LOG.error(failedMsg + " Please restore backups and roll back database and code!");

            stopWatch.stop();
            int executionTime = (int) stopWatch.getTotalTimeMillis();
            AppliedMigration appliedMigration = new AppliedMigration(version, migration.getDescription(),
                    migration.getType(), migration.getScript(), migration.getChecksum(), executionTime, false);
            metaDataTable.addAppliedMigration(appliedMigration);
        }
        throw e;
    }

version 4.2

        }
    } catch (FlywayMigrateSqlException e) {
        MigrationInfoImpl migration = e.getMigration();
        String failedMsg = "Migration of " + toMigrationText(migration, e.isOutOfOrder()) + " failed!";
        if (dbSupport.supportsDdlTransactions() && executeGroupInTransaction) {
            LOG.error(failedMsg + " Changes successfully rolled back.");
        } else {
            LOG.error(failedMsg + " Please restore backups and roll back database and code!");

            stopWatch.stop();
            int executionTime = (int) stopWatch.getTotalTimeMillis();
            AppliedMigration appliedMigration = new AppliedMigration(migration.getVersion(), migration.getDescription(),
                    migration.getType(), migration.getScript(), migration.getResolvedMigration().getChecksum(), executionTime, false);
            metaDataTable.addAppliedMigration(appliedMigration);
        }
        throw e;
    }

[axelfontaine]

Good catch! I am actually amazed this managed to slip through and go unnoticed for so long. Thanks for reporting and investigating. Fixed.