fix(migrations): exempt internal own-company from duplicate-name unique index (staging hotfix, PMS-413) #311

Merged

vas2000-work merged 1 commit from fix/PMS-413-own-company-name-unique-collision into main

2026-06-18 07:30:51 +02:00

vas2000-work commented

2026-06-18 07:23:47 +02:00

Owner

Hotfix: staging mokosh-server crash-looped immediately after the PMS-413 deploy because migration 062's backfill (create one internal company per tenant, named after the tenant) violated PMS-400's idx_companies_tenant_name_unique (tenant_id, lower(btrim(name))) on any tenant that already held a company named like the tenant. The migration aborts (fatal at boot), so the server never starts.

Fix: 062 now recreates that index as a PARTIAL unique index WHERE company_type <> 'internal' before the backfill, and the runtime duplicate-name checks in create_company / update_company exempt internal too. The own-company is a system row exempt from the customer duplicate-name rule. Reproduced the exact unique violation locally and verified the corrected migration applies cleanly against colliding data; clippy + contacts (incl company_rejects_duplicate_name) + tenants integration all green.

Editing migration 062 in place is safe: it failed transactionally on staging (never recorded in _sqlx_migrations), and production ships via releases so 062 has not been applied there.

#PMS-413

Hotfix: staging mokosh-server crash-looped immediately after the PMS-413 deploy because migration 062's backfill (create one `internal` company per tenant, named after the tenant) violated PMS-400's `idx_companies_tenant_name_unique (tenant_id, lower(btrim(name)))` on any tenant that already held a company named like the tenant. The migration aborts (fatal at boot), so the server never starts. Fix: 062 now recreates that index as a PARTIAL unique index `WHERE company_type <> 'internal'` before the backfill, and the runtime duplicate-name checks in `create_company` / `update_company` exempt internal too. The own-company is a system row exempt from the customer duplicate-name rule. Reproduced the exact unique violation locally and verified the corrected migration applies cleanly against colliding data; clippy + contacts (incl `company_rejects_duplicate_name`) + tenants integration all green. Editing migration 062 in place is safe: it failed transactionally on staging (never recorded in `_sqlx_migrations`), and production ships via releases so 062 has not been applied there. #PMS-413

vas2000-work added 1 commit

2026-06-18 07:23:47 +02:00

fix(migrations): exempt internal own-company from the duplicate-name unique index (PMS-413)

E2E / Playwright against staging (pull_request) Failing after 16s

Details

Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 1m52s

Details

Integration / integration tests (pull_request) Successful in 6m31s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

31132b3917

Migration 062's backfill creates an internal company named after the tenant, but PMS-400's idx_companies_tenant_name_unique (tenant_id, lower(btrim(name))) rejected it on any tenant that already held a company named like the tenant, aborting the migration and crash-looping staging right after the PMS-413 deploy. Recreate that index as a partial unique index excluding internal companies BEFORE the backfill, and exempt internal from the runtime duplicate-name checks (create + update) for consistency. The own-company is a system row and is not subject to the customer duplicate-name rule. Editing 062 is safe: it failed transactionally on staging (unrecorded) and has not shipped to prod (release-gated).

#PMS-413