Flyway (9.17.0), Quarkus failed to start after upgrading from 2.13.x to 3.2.0.final ==> Migrations have failed validation

[miqui]

Upgraded from 2.13.x to 3.2.0-final and now our quarkus instance won't start due to the failed flyway validation. We, do have java/jdbc script in the classpath (but, not under convention /db/migration like our other sql scripts). Any hints? Thanks.

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2023-09-19 18:48:29,833 WARN  [org.hib.id.UUIDHexGenerator] (main) HHH000409: Using org.hibernate.id.UUIDHexGenerator which does not generate IETF RFC 4122 compliant UUID values; consider using org.hibernate.id.UUIDGenerator instead
2023-09-19 18:48:35,133 INFO  [org.fly.cor.int.lic.VersionPrinter] (main) Flyway Community Edition 9.17.0 by Redgate
2023-09-19 18:48:35,133 INFO  [org.fly.cor.int.lic.VersionPrinter] (main) See release notes here: https://rd.gt/416ObMi
2023-09-19 18:48:35,134 INFO  [org.fly.cor.int.lic.VersionPrinter] (main) 
2023-09-19 18:48:36,546 INFO  [org.fly.cor.int.dat.bas.BaseDatabaseType] (main) Database: jdbc:postgresql: *****
2023-09-19 18:48:37,037 ERROR [io.qua.run.Application] (main) Failed to start application (with profile [dev]): java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.runner.ApplicationImpl.doStart(Unknown Source)
	at io.quarkus.runtime.Application.start(Application.java:101)
	at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:111)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:71)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:44)
	at io.quarkus.runtime.Quarkus.run(Quarkus.java:124)
	at io.quarkus.runner.GeneratedMain.main(Unknown Source)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:61)
	at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:32)
Caused by: org.flywaydb.core.api.exception.FlywayValidateException: Validate failed: Migrations have failed validation
Detected applied migration not resolved locally: 1.0.19.
If you removed this migration intentionally, run repair to mark the migration as deleted.
Need more flexibility with validation rules? Learn more: https://rd.gt/3AbJUZE
	at org.flywaydb.core.Flyway.lambda$migrate$0(Flyway.java:146)
	at org.flywaydb.core.FlywayExecutor.execute(FlywayExecutor.java:196)
	at org.flywaydb.core.Flyway.migrate(Flyway.java:140)
	at io.quarkus.flyway.runtime.FlywayRecorder.doStartActions(FlywayRecorder.java:93)
	at io.quarkus.deployment.steps.FlywayProcessor$startActions2035800939.deploy_0(Unknown Source)
	at io.quarkus.deployment.steps.FlywayProcessor$startActions2035800939.deploy(Unknown Source)

[miqui]

update: added the location param to our properties file. Runs ok local, but when we deploy to ROSA it seems some how this setting is not getting sourced by Flyway.

[gsmet]

I don't see any reason why it would work locally and not when deploying.

You don't have an environment variable overriding the location somewhere?

[miqui]

Hi @gsmet

So, digging around logs, docs. We finally got around to realize the subtle point of build time vs runtime settings. So, we added the locations override and the problem was resolved. Kinda nasty this change in behaviour simply upgrading Quarkus. However, my experience tells me that when you make a major jump then funky stuff is gonna happen, we just did not understand what the errors where telling us. Thanks for your reply.