Summary
DataProviderMigrate migrate against an existing Postgres DB, when a schema change adds a new column with a foreign key to an existing table, applies the AddColumnOperation (+ index + RLS policies) but does not plan a CreateForeignKeyOperation for that column. The post-migration integrity check then fails because the FK declared in the schema is absent from the DB.
Repro
Schema adds to existing table usage_events:
- column
end_user_id Uuid (nullable)
- FK
end_user_id -> tenant_end_users(id) ON DELETE SET NULL
- index + RLS policies
Run migrate --provider postgres against a DB that already has usage_events.
Observed
Phase: all — applying 7 of 7 operation(s):
AddColumnOperation
CreateIndexOperation
CreateRlsPolicyOperation x5
Migration completed successfully
SCHEMA INTEGRITY CHECK FAILED
public.usage_events: missing foreign key FK_usage_events_end_user_id on (end_user_id)
No CreateForeignKeyOperation is ever planned. Re-running reports "Schema is up to date — no operations needed" yet the same integrity check still fails → migrate can never converge for this change on an existing DB; exit code 1.
Expected
Adding a column that declares a FK should also plan a CreateForeignKeyOperation (as it would when creating the table fresh — a fresh-DB run creates the FK with the table, so this only repros incrementally).
Impact
Blocks clean incremental prod migrations that add a FK-bearing column; forces operators toward a raw-SQL workaround (which our project policy forbids). Cosmetic aside: integrity check also flags default expected 'pending' but found 'pending'::text (Postgres text-cast normalization false positive).
Summary
DataProviderMigrate migrateagainst an existing Postgres DB, when a schema change adds a new column with a foreign key to an existing table, applies theAddColumnOperation(+ index + RLS policies) but does not plan aCreateForeignKeyOperationfor that column. The post-migration integrity check then fails because the FK declared in the schema is absent from the DB.Repro
Schema adds to existing table
usage_events:end_user_id Uuid(nullable)end_user_id -> tenant_end_users(id) ON DELETE SET NULLRun
migrate --provider postgresagainst a DB that already hasusage_events.Observed
No
CreateForeignKeyOperationis ever planned. Re-running reports "Schema is up to date — no operations needed" yet the same integrity check still fails → migrate can never converge for this change on an existing DB; exit code 1.Expected
Adding a column that declares a FK should also plan a
CreateForeignKeyOperation(as it would when creating the table fresh — a fresh-DB run creates the FK with the table, so this only repros incrementally).Impact
Blocks clean incremental prod migrations that add a FK-bearing column; forces operators toward a raw-SQL workaround (which our project policy forbids). Cosmetic aside: integrity check also flags
default expected 'pending' but found 'pending'::text(Postgres text-cast normalization false positive).