Flyway migration error details with Spring Boot

user_923712 0
Viewed 3027

We have a project using Spring Boot and flyway.

When we run a migration that fails, with logs levels all set to DEBUG, we only got these messages:

[DEBUG] org.flywaydb.core.internal.command.DbValidate - Validating migrations ...
[DEBUG] org.flywaydb.core.internal.scanner.Scanner - Filtering out resource: db/migration/V1/V1_202103081030__account.sql (filename: V1_202103081030__account.sql)
[DEBUG] org.flywaydb.core.internal.scanner.Scanner - Filtering out resource: db/migration/V1/V1_202103081040__place.sql (filename: V1_202103081040__place.sql)
[DEBUG] org.flywaydb.core.internal.scanner.Scanner - Filtering out resource: db/migration/V1/V1_202103151608__document.sql (filename: V1_202103151608__document.sql)
[DEBUG] org.flywaydb.core.Flyway - Memory usage: 147 of 254M
[ERROR] org.springframework.boot.web.embedded.tomcat.TomcatStarter - Error starting Tomcat context. Exception: org.springframework.beans.factory.UnsatisfiedDependencyException. Message: Error creating bean with name 'webSecurityConfig': Unsatisfied dependency expressed through method 'setContentNegotationStrategy' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$EnableWebMvcConfiguration': Unsatisfied dependency expressed through method 'setConfigurers' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'openEntityManagerInViewInterceptorConfigurer' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/JpaBaseConfiguration$JpaWebConfiguration.class]: Unsatisfied dependency expressed through method 'openEntityManagerInViewInterceptorConfigurer' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'openEntityManagerInViewInterceptor' defined in class path resource [org/springframework/boot/autoconfigure/orm/jpa/JpaBaseConfiguration$JpaWebConfiguration.class]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flywayInitializer' defined in class path resource [org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration$FlywayConfiguration.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.exception.FlywayValidateException: Validate failed: Migrations have failed validation
...
[INFO ] org.apache.catalina.core.StandardService - Stopping service [Tomcat]
...
Caused by: org.flywaydb.core.api.exception.FlywayValidateException: Validate failed: Migrations have failed validation

There is no more details about the reason of the failure (a failing query, an unmatched checksum, ...).

I look at the spring.flyway application properties but found nothing that could be of any help here.

What should we do to display the flyway root error in our logs at server startup?

EDIT: To be clear, the problem is not the failure itself (setting a breakpoint in Flyway classes can reveal the source error). The problem is the missing error details in the logs.

flyway spring-boot spring
3 Answers

I was having the same problem and found that it was related to the Flyway version I was on (Spring Boot 2.4.3, which uses Flyway 7.1.1). It's a known issue 2987 - Display all validate messages in exceptions, fixed in Flyway 7.2.0.

They recommend running flyway validate -outputType=json as a workaround to get a detailed error message. I tried that, but still didn't get a detailed error message.

The solution that worked for me was upgrading to Flyway 7.2.0, by specifying the version in my pom file:

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
    <version>7.2.0</version>
</dependency>
user_51555500

I don't know specifically what is failing, but this might help point you in the right direction.

  1. Open up DbValidate (flyway class). (Download sources if you need to)
  2. Put a break point in the else statement on lines 186-187
  3. Start server again

That will at least tell you which file is failing.

You then might be able to make an enhancement request to the Flyway project for better error reporting.

user_17972630

Well, a lot of things can happen, but one possible reason is that you've changed the migration file after you've applied it already. I'll explain by use case:

Let's say that at time X you have 2 migrations (technically implemented in SQL files): A1 and A2.

This is your first commit with A1 and A2 and when you run the application, flyway creates a special table in the database to see which migrations were already applied. Obviously, there are no migrations there yet at time X so it creates a table, applies A1 and A2, and adds 2 records in the table. These records among other things should include a checksum. Simply put you can think about these checksum as a hash (like sha1) of the content of A1 and A2 correspondingly.

So far so good, now fast forward in time (to time Y) when you introduce a new migration file A3.

When you re-deploy the application, flyway checks that A1 and A2 that have already been applied have not changed, and only after that it applies the new migration.

Now, this validation is really a prerequisite to applying migration A3 checks these hashes - checksums. This is reasonable - because if you happen to have changed A1 or A2 - what should the flyway do - how it can guarantee that migrations work as expected?

You can read also in the official flyway documentation about this validation, however, you get the idea I believe. Someone has changed the checksum by changing one of your existing migrations and have tried to redeploy the applications.

Simply put, Once the migration file has been applied - it can't be changed in a source tree

Now the scenario that I've described is one possible scenario, in general, you don't really have to even create migration A3, it is enough to change the existing migration and try to re-run the application - the validation will fail.

user_6051530
Related