Flowable Engine Version Migrations to survive idempotency

Flowable Engine
1

Hi, we’re using Flowable 7.2.0 embedded in our OpenSource application OpenMetadata which uses DropWizard for backend. We’ve run into a scenario where the application crashes mid-startup during a Flowable schema upgrade (e.g. due to an infrastructure issue). When this happens, the ACT_GE_PROPERTY version row still reflects the old version, but some DDL objects (indexes, tables, columns) from the upgrade scripts have already been created.

On restart, Flowable tries to re-run the upgrade scripts from the old version, and fails on “already exists” errors, leaving the database permanently stuck, ideally not allowing us to start the application because of the DB crash as both Flowable and our application uses the same data.

Constraints: DDL Schema upgrades are needed for us, We cannot disable the schema upgrades, We cannot reset the DB manually, as it may lose data which we want from the older processes, and we are looking for a way to handle this without manual intervention.

We are try to work this around this by wrapping the DataSource so that CREATE INDEX, CREATE TABLE, and ALTER TABLE ADD COLUMN statements are pre checked against DatabaseMetaData before execution, skipping objects that already exist. This works but is an application overhead and it feels like something Flowable could handle natively.

A few questions:

  1. Is there a built-in configuration or hook to make upgrade scripts idempotent or resumable after a partial failure?

  2. Would you consider adding IF NOT EXISTS to the upgrade scripts (at least for PostgreSQL where it’s supported)?

  3. Is there a recommended recovery path for a partially-upgraded schema, short of manually fixing the ACT_GE_PROPERTY version row? Sometimes when there are partial upgrades, fixing this row skips the migration, now our database is in a partial state, tomorrow for the next set of migrations, we are stuck, because the previous migrations didnt run as expected.