Flyway error java.lang.IllegalArgumentException

Trying to run Flyway, I get the following error

ERROR: java.lang.IllegalArgumentException: No enum constant org.flywaydb.core.api.MigrationType.DELETE

My command is

flyway -user=???? -password=???? -locations="filesystem:." -configFiles=flyway-control-uat.conf migrate 

I have tried using "repair" as well as "migrate" but with the same result

My version of flyway is Flyway Community Edition 6.5.5 by Redgate

Thanks

PS: we have been using flyway quite a lot without issue so far

4 Answers

As Eric Mament mentioned this happened to me when I tried to repair a database where Flyway 6 was used, using my local Flyway 7.

The way I fixed this is simply by deleting the rows from the flyway schema history table which were not backwards compatible with Flyway 6.

DELETE FROM flyway_schema_history where type = 'DELETE' 

Afterwards I ran flyway validate, using local version 6 and it worked

flyway validate 

My workstation had Flyway community edition v6.5.

A colleague of mine had updated his version to v7.5 and performed some migrations on our database.

The way I fixed the immediate problem was to uninstall flyway from our database (not uninstall the software itself). Then run a new baseline and this worked.

However, I had taken a backup of the database before doing this. So following the comment from Julia Hayward, I updated my own version to v7.5 and the problem disappeared (from the copy I had made).

So my understanding is that trying to "migrate" my database with v6.5 while someone else had already "migrated" with v7.5, combined with the various changes we did in our scripts ended up with this unhappy situation.

So if it happens to you, make sure you are all on the same version.

A similar issue happened with me, although it was an issue on our end. Exception message was No enum constant org.flywaydb.core.api.MigrationType. (notice no value after MigrationType. instead of MigrationType.DELETE in the question.). The issue was that the type column of one row in the flyway_schema_history table was empty due to manually inserting that row.

Details

It was happening for only one database; the rest of the other databases were being migrated without any issues. When I checked the stack trace, I dug into the flyway code.

at java.lang.Enum.valueOf(Enum.java:238) at org.flywaydb.core.api.MigrationType.valueOf(MigrationType.java:21) at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:215) at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:195) at org.flywaydb.core.internal.jdbc.JdbcTemplate.query(JdbcTemplate.java:381) at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.refreshCache(JdbcTableSchemaHistory.java:195) at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.allAppliedMigrations(JdbcTableSchemaHistory.java:185) at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:131) at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:142) at org.flywaydb.core.internal.command.DbValidate$2.call(DbValidate.java:130) at org.flywaydb.core.internal.jdbc.TransactionalExecutionTemplate.execute(TransactionalExecutionTemplate.java:66) at org.flywaydb.core.internal.command.DbValidate.validate(DbValidate.java:130) at org.flywaydb.core.Flyway.doValidate(Flyway.java:286) at org.flywaydb.core.Flyway.access$100(Flyway.java:73) at org.flywaydb.core.Flyway$1.execute(Flyway.java:166) at org.flywaydb.core.Flyway$1.execute(Flyway.java:158) at org.flywaydb.core.Flyway.execute(Flyway.java:527) at org.flywaydb.core.Flyway.migrate(Flyway.java:158) at X.Y.Z.A.B.C.FlywayMigrationService.runMigration(FlywayMigrationService.java:47) 

At line org.flywaydb.core.internal.schema history.JdbcTableSchemaHistory$2.mapRow(JdbcTableSchemaHistory.java:215), Flyway queries the flyway_schema_history table, goes through each row, pick the value in the type column, does MigrationType.valueOf(type), and other such stuff.

Since the value of a row's type column was empty, the valueOf broke. Once we deleted this culprit row, it started working fine.

In my case, I just did below simple things in rush time:

Deleted all the records from the schema (history)version table.

DELETE FROM Schema_Version WHERE [TYPE] = 'DELETE'

And rerun a flyway migration. This has resolved the issue.