null string exception when executing Flyway command on Spanner database after upgrading from 8.0.0 to 10.1.0

[DuanHen]

Which version and edition of Flyway are you using?

Flyway 10.1.0 Community Edition

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)

This issue occurs in the latest version

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

Gradle plugin

Which database are you using? (Type & version)

Google Cloud Spanner

Which operating system are you using?

windows

What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)

After upgrading Flyway from version 8.0.0 to 10.1.0, executing the Flyway command against a Google Cloud Spanner database results in a null string exception.

Execution failed for task ':flywayInfo'.
> Error occurred while executing flywayInfo
  null string

What did you expect to see?

I expected the Flyway commands to execute normally without any errors, just as they did with version 8.0.0.

What did you see instead?

A null string exception occurred. This seems to be due to a change in the handling of the 'installed_on' column in the 'flyway_schema_history' table. In versions prior to 8.1.0, this column was allowed to be null. In version 10.1.0, the refreshCache method was updated with the following logic:

https://github.com/flyway/flyway/blob/flyway-10.1.0/flyway-core/src/main/java/org/flywaydb/core/internal/schemahistory/JdbcTableSchemaHistory.java#L224C1-L227C18

Timestamp installedOn = rs.getTimestamp(columnOrdinalMap.get("installed_on"));
if (installedOn == null) {
    installedOn = Timestamp.valueOf(rs.getString(columnOrdinalMap.get("installed_on")));
}

When installedOn is null, the Timestamp.valueOf(rs.getString(columnOrdinalMap.get("installed_on"))); conversion fails.

[lukassailer]

Any news on this?
I have encountered the same issue when trying to upgrade our flyway version.

I found this Stackoverflow Post with a fix but i would prefer not to change the column definition of the flyway table.

[lukassailer]

We found out that the problem occurs on old systems, which before Flyway version 6 (or so) had the table schema_version, which was renamed to flyway_schema_history.
We renamed the table with a migration.

rename migration code

DO
$$
    BEGIN
        IF (EXISTS(SELECT 1 FROM information_schema.tables WHERE table_schema = 'public' AND table_name = 'schema_version')
            AND EXISTS(SELECT 1 FROM information_schema.tables WHERE table_schema = 'public' AND table_name = 'flyway_schema_history'))
        THEN
            DROP TABLE schema_version;
        END IF;
        IF (EXISTS(SELECT 1 FROM information_schema.tables WHERE table_schema = 'public' AND table_name = 'schema_version')
            AND NOT EXISTS(SELECT 1 FROM information_schema.tables WHERE table_schema = 'public' AND table_name = 'flyway_schema_history'))
        THEN
            CREATE TABLE flyway_schema_history AS TABLE schema_version;
        END IF;
    END
$$;

However, this only changed the name of the table. And, for those tables that were renamed and not created, did not apply flyways new table definition which has column constraints.

correct definition

CREATE TABLE flyway_schema_history
(
    installed_rank INTEGER                                   NOT NULL,
    version        CHARACTER VARYING(50),
    description    CHARACTER VARYING(200)                    NOT NULL,
    type           CHARACTER VARYING(20)                     NOT NULL,
    script         CHARACTER VARYING(1000)                   NOT NULL,
    checksum       INTEGER,
    installed_by   CHARACTER VARYING(100)                    NOT NULL,
    installed_on   TIMESTAMP WITHOUT TIME ZONE DEFAULT NOW() NOT NULL,
    execution_time INTEGER                                   NOT NULL,
    success        BOOLEAN                                   NOT NULL
);

I am unsure what the correct migration from schema_version to flyway_schema_history would have been. Everything i can find online suggest you were supposed to just rename the table.