[blocker] Dapper PostgreSQL migrations skip all create-table branches with FluentMigrator 7.2 ("PostgreSQL" vs "Postgres") #255

Found by Code Review while testing #251 / #252.

Summary

The Dapper migrations gate every create-table branch on IfDatabase("SqlServer", "Oracle", "MySql", "Postgres"). With FluentMigrator 7.2, the PostgreSQL processor never reports "Postgres": AddPostgres() registers Postgres15_0Processor, which reports DatabaseType = "PostgreSQL15_0" and aliases { "PostgreSQL15_0", "PostgreSQL" }. IfDatabase does an exact (case-insensitive) match against the processor's DatabaseType plus DatabaseTypeAliases, so "Postgres" never matches. Every create-table branch (both the SQL Server/Oracle/MySql/Postgres branch and the Sqlite branch) is skipped on PostgreSQL.

Result: on a fresh Dapper + PostgreSQL install, migration 10001 (Elsa:Management:V3.0) creates nothing and then 10002 (Elsa:Management:V3.1) fails, because it runs Alter.Table("WorkflowDefinitions").AddColumn("IsSystem") against a table that doesn't exist.

This already fails on release/3.9.0 before #251, so #251 didn't cause it.

Affected files / pattern

Same on release/3.9.0, main and release/3.8.4 (the files are identical across these branches):

• src/modules/persistence/Elsa.Persistence.Dapper.Migrations/Management/Initial.cs (migration 10001): 2× IfDatabase("SqlServer", "Oracle", "MySql", "Postgres") (tables WorkflowDefinitions, WorkflowInstances)
• src/modules/persistence/Elsa.Persistence.Dapper.Migrations/Runtime/Initial.cs (migration 20001): 4× the same IfDatabase(...) create-table branches
• src/modules/persistence/Elsa.Persistence.Dapper.Migrations/Runtime/V3_3.cs (migration 20004): 1× the same pattern
• Failure surfaces at src/modules/persistence/Elsa.Persistence.Dapper.Migrations/Management/V3_1.cs (migration 10002), the first migration that assumes the tables exist.

The Identity migrations don't use IfDatabase.

FluentMigrator 7.2.0 references:

• PostgresRunnerBuilderExtensions.AddPostgres() registers Postgres15_0Processor as IMigrationProcessor. In 6.2.0 it registered the base PostgresProcessor, whose DatabaseType is "Postgres".
• Postgres15_0Processor: DatabaseType => ProcessorIdConstants.PostgreSQL15_0, aliases PostgreSQL15_0, PostgreSQL. Postgres10_0Processor and Postgres11_0Processor follow the same pattern.
• IfDatabaseExpressionRoot.DatabaseTypeApplies: exact set match on DatabaseType plus aliases.

Is 3.8.4 affected?

FluentMigrator versions in Directory.Packages.props (central package management; the Dapper csproj files don't override versions):

Conclusion: FluentMigrator 7.2 did not come in with 3.9. It has been pinned at 7.2.0 since at least 3.6.0, and the affected migration files on release/3.8.4 are identical to release/3.9.0. So 3.8.4 (and earlier 3.6–3.8 releases) are very likely affected too, which makes this a pre-existing bug rather than a 3.9 regression.

Caveat: this repo doesn't reference FluentMigrator.Runner.Postgres. The host adds it and calls AddPostgres() in DapperMigrationsFeature.ConfigureRunner, so the processor that actually runs depends on the host's runner package. Any 7.x Runner.Postgres (which is what FluentMigrator 7.2.0 core pairs with) defaults to Postgres15_0Processor and is affected. I haven't reproduced this on 3.8.4 at runtime. This conclusion comes from reading the code and package versions.

Suggested fix

• Make the PostgreSQL gate match the processor's current identifiers, e.g. IfDatabase("SqlServer", "Oracle", "MySql", "Postgres", "PostgreSQL"), preferably via ProcessorIdConstants rather than string literals. Another option is the predicate overload (IfDatabase(t => t.StartsWith("Postgres", StringComparison.OrdinalIgnoreCase))), which also covers PostgreSQL15_0, Postgres92, and so on. Apply this to all occurrences in Management/Initial.cs, Runtime/Initial.cs and Runtime/V3_3.cs.
• Add a test that runs the full Dapper migration set against a fresh PostgreSQL database (e.g. Testcontainers) using AddPostgres(), and asserts that all migrations apply and the expected tables exist. The current Elsa.Persistence.Dapper.UnitTests only reference FluentMigrator.Runner.SQLite, which is why this went unnoticed.

Target

ext 3.9 blocker. Fix on release/3.9.0 and main.