flyway failes to insert installed_on timestamp when running a migration

linde98

###### Which version and edition of Flyway are you using?

10.16.0

###### Which client are you using? 

Java API

###### Which database are you using? (Type & version)

mysql  Ver 8.0.37 (MySQL Community Server - GPL)

###### Which operating system are you using?

Linux x86_64 

###### What did you do? 

I have a program which applies migration running within a CI. No special configuration settings or otherwise are used.  

```kotlin

val config = Configuration.loadConfiguration()

val flyway = Flyway.configure()

    .dataSource(config.jdbcUrl, config.username, config.password)

    .schemas("myproject")

    .locations(config.migrationsPath)

    .load()

flyway.migrate()

```

###### What did you expect to see?

I expect that flyway terminates successfully while setting the correct `installed_on` timestamp in the `flyway_schema_history` table. 

###### What did you see instead?

The migrations are applied correctly however the insertion of the `installed_on` field in the `flyway_schema_history` fails. The rest of the fields in the table are set correctly. This exception occurs:

```

Error: Exception in thread "main" java.lang.IllegalArgumentException: null string

at java.sql/java.sql.Timestamp.valueOf(Timestamp.java:190)

at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.lambda$refreshCache$1(JdbcTableSchemaHistory.java:2[31](https://github.com/My-Project/DataImport-Migrations/actions/runs/10029633569/job/27718076662#step:4:32))

at org.flywaydb.core.internal.jdbc.JdbcTemplate.query(JdbcTemplate.java:359)

at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.refreshCache(JdbcTableSchemaHistory.java:207)

at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.allAppliedMigrations(JdbcTableSchemaHistory.java:198)

at org.flywaydb.core.internal.info.MigrationInfoServiceImpl.refresh(MigrationInfoServiceImpl.java:87)

at org.flywaydb.core.internal.command.DbMigrate.migrateGroup(DbMigrate.java:176)

at org.flywaydb.core.internal.command.DbMigrate.lambda$migrateAll$0(DbMigrate.java:146)

at org.flywaydb.database.mysql.MySQLNamedLockTemplate.execute(MySQLNamedLockTemplate.java:62)

at org.flywaydb.database.mysql.MySQLConnection.lock(MySQLConnection.java:154)

at org.flywaydb.core.internal.schemahistory.JdbcTableSchemaHistory.lock(JdbcTableSchemaHistory.java:149)

at org.flywaydb.core.internal.command.DbMigrate.migrateAll(DbMigrate.java:146)

at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:104)

at org.flywaydb.core.Flyway.lambda$migrate$0(Flyway.java:222)

at org.flywaydb.core.FlywayExecutor.execute(FlywayExecutor.java:210)

at org.flywaydb.core.Flyway.migrate(Flyway.java:164)

at my.project.dataImporter.migrations.DataImportMigrations.runMigrations(DataImportMigrations.kt:27)

at my.project.dataImporter.migrations.DataImportMigrationsKt.main(DataImportMigrations.kt:[34]

> Task :app:run FAILED

``` 

Furthermore this issue did not occur in the beginning. It just randomly started.

AlistairW

For MySQL, Flyway relies on the DB to insert the timestamp in the schema history table (see this line) - it looks like the error is happening when Flyway tries to read it back again. Can you see if there is sensible data in the schema history table for the installed_on field ?

linde98

After a migration is run the column `installed_on` is `null`. 

I also tried to get a timestamp manually by running `select  CURRENT_TIMESTAMP() ` which works as expected. 

AlistairW

That's very curious. I also realize that the link I put above is inaccessible - I've updated it now but it should have been the one in the  flyway/flyway repository.
I'll discuss it with the team to see if they have any ideas - all I've got at the moment is whether you are using the MariaDB driver and it has some strange compatibility issue ... but that is very tenuous
https://documentation.red-gate.com/fd/mysql-184127601.html

Jason_L

Hi linde98,

I believe you've brought up the same issue here https://github.com/flyway/flyway/issues/3927. We can continue to follow up this issue under than ticket.