Split db-init into pre-schema and post-schema phases

CI dry-run revealed an architectural ordering bug: db-init/004 and db-init/005 ALTER TABLE the Directus-managed tables (organization_users, events, etc.), but db-init runs BEFORE schema-apply creates those tables. On a fresh CI Postgres this fails with "relation does not exist." Local dev never tripped this because we'd created the tables via MCP first. Fix: introduce a post-schema migration phase. Two db-init runs in the entrypoint, with schema-apply in between: 1. apply-db-init.sh db-init/ → positions hypertable + faulty column (tables Directus does NOT manage) 2. schema-apply.sh → creates Directus-managed tables from snapshots/schema.yaml 3. apply-db-init.sh db-init-post/ → composite UNIQUE constraints on the Directus-managed tables 4. directus bootstrap 5. directus start Files moved: db-init/004_junction_unique_constraints.sql → db-init-post/001_junction_unique_constraints.sql db-init/005_event_participation_unique_constraints.sql → db-init-post/002_event_participation_unique_constraints.sql Each ALTER TABLE in the post-schema migrations is now wrapped in a pg_constraint existence guard for idempotency. This handles the dev DB where the constraints already exist (from the original 004/005 runs + the manual psql recovery during task 1.5's destructive-apply incident). Old 004/005 rows in migrations_applied become orphans — harmless. Updates: - Dockerfile: COPY db-init-post into the image - entrypoint.sh: 4-step → 5-step flow with the post-schema run between schema-apply and bootstrap - .gitea/workflows/build.yml: dry-run chains all three pre-boot scripts (pre-schema → schema-apply → post-schema); path filter includes db-init-post/** - Task specs 1.4 and 1.5 Done sections: updated to reference the new db-init-post/ path (db-init/004 → db-init-post/001, etc.) The reusable runner script (apply-db-init.sh) didn't need to change — it already accepts DB_INIT_DIR and uses just the basename for the guard-table key. The two phases share migrations_applied; filenames don't collide because pre-schema and post-schema use distinct descriptive names. Phase 1 is still "done" — this is a Phase 1 architectural correction exposed by the CI dry-run, not a new task.
2026-05-02 10:47:52 +02:00
parent 82615c0a66
commit e01abfef27
10 changed files with 245 additions and 157 deletions
@@ -0,0 +1,21 @@
+# Post-schema migrations applied AFTER directus schema apply runs.
+#
+# Pre-schema migrations live in ../db-init/ — they create tables that
+# Directus does NOT manage (positions hypertable, faulty column, future
+# PostGIS extension). Post-schema migrations live here — they constrain
+# tables that Directus DOES manage (organization_*, events, entries,
+# entry_*, classes), which are created by `directus schema apply` from
+# the snapshot YAML during entrypoint step 2/5.
+#
+# Order at boot:
+#   1. apply-db-init.sh    DB_INIT_DIR=/directus/db-init       (pre-schema)
+#   2. schema-apply.sh                                          (Directus tables created)
+#   3. apply-db-init.sh    DB_INIT_DIR=/directus/db-init-post   (post-schema)
+#   4. directus bootstrap
+#   5. directus start
+#
+# Both pre- and post- runs share the same `migrations_applied` guard
+# table. Filenames must be unique across both directories (which they
+# are by convention — pre-schema files start with descriptive names
+# from the table they create; post-schema files start with descriptive
+# names from the constraint they add).
@@ -0,0 +1,80 @@
+-- 001_junction_unique_constraints.sql (post-schema phase)
+-- Composite UNIQUE constraints on the org-junction tables.
+--
+-- Why post-schema?
+--   The tables this migration constrains (organization_users,
+--   organization_vehicles, organization_devices) are Directus-managed —
+--   created by `directus schema apply` from snapshots/schema.yaml during
+--   entrypoint step 2/5.  Pre-schema migrations (db-init/) cannot reference
+--   them because they don't exist yet at that point.  This file lives in
+--   db-init-post/ which the runner walks AFTER schema-apply.
+--
+-- Why composite uniqueness lives here at all (not in the snapshot YAML)?
+--   Directus's snapshot format only captures single-column unique
+--   constraints (the field-level `is_unique` flag).  Composite uniqueness
+--   is enforced via raw DDL.
+--
+-- Idempotency: each ALTER TABLE is wrapped in a `pg_constraint` existence
+--   check so the migration is safe to apply against a database where the
+--   constraints were created out-of-band (e.g. via psql during the dev
+--   recovery from the schema-apply destructive-delete incident in task
+--   1.5).  The runner's checksum guard is a separate layer; this guard
+--   protects against state drift that the runner can't see.
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'organization_users_org_user_unique'
+  ) THEN
+    ALTER TABLE organization_users
+      ADD CONSTRAINT organization_users_org_user_unique
+      UNIQUE (organization_id, user_id);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'organization_vehicles_org_vehicle_unique'
+  ) THEN
+    ALTER TABLE organization_vehicles
+      ADD CONSTRAINT organization_vehicles_org_vehicle_unique
+      UNIQUE (organization_id, vehicle_id);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'organization_devices_org_device_unique'
+  ) THEN
+    ALTER TABLE organization_devices
+      ADD CONSTRAINT organization_devices_org_device_unique
+      UNIQUE (organization_id, device_id);
+  END IF;
+END $$;
+
+-- -------------------------------------------------------------------------
+-- Assertion block: verify all three constraints landed.
+-- -------------------------------------------------------------------------
+DO $$ BEGIN
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_users_org_user_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_users composite unique constraint missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_vehicles_org_vehicle_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_vehicles composite unique constraint missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_devices_org_device_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_devices composite unique constraint missing';
+  END IF;
+
+END $$;
@@ -0,0 +1,97 @@
+-- 002_event_participation_unique_constraints.sql (post-schema phase)
+-- Composite UNIQUE constraints on the event-participation collections.
+--
+-- Same rationale as 001 in this dir: tables are Directus-managed (events,
+-- classes, entries, entry_crew, entry_devices), created by schema-apply,
+-- so the constraints land here in db-init-post/ rather than in db-init/.
+--
+-- All ALTER TABLE statements are wrapped in pg_constraint existence guards
+-- for idempotency against pre-existing constraints (see 001 for full
+-- rationale).
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'events_org_slug_unique'
+  ) THEN
+    ALTER TABLE events
+      ADD CONSTRAINT events_org_slug_unique
+      UNIQUE (organization_id, slug);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'classes_event_code_unique'
+  ) THEN
+    ALTER TABLE classes
+      ADD CONSTRAINT classes_event_code_unique
+      UNIQUE (event_id, code);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entries_event_race_number_unique'
+  ) THEN
+    ALTER TABLE entries
+      ADD CONSTRAINT entries_event_race_number_unique
+      UNIQUE (event_id, race_number);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entry_crew_entry_user_unique'
+  ) THEN
+    ALTER TABLE entry_crew
+      ADD CONSTRAINT entry_crew_entry_user_unique
+      UNIQUE (entry_id, user_id);
+  END IF;
+END $$;
+
+DO $$ BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entry_devices_entry_device_unique'
+  ) THEN
+    ALTER TABLE entry_devices
+      ADD CONSTRAINT entry_devices_entry_device_unique
+      UNIQUE (entry_id, device_id);
+  END IF;
+END $$;
+
+-- -------------------------------------------------------------------------
+-- Assertion block: verify all five constraints landed.
+-- -------------------------------------------------------------------------
+DO $$ BEGIN
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'events_org_slug_unique'
+  ) THEN
+    RAISE EXCEPTION 'events composite unique constraint (org, slug) missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'classes_event_code_unique'
+  ) THEN
+    RAISE EXCEPTION 'classes composite unique constraint (event, code) missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entries_event_race_number_unique'
+  ) THEN
+    RAISE EXCEPTION 'entries composite unique constraint (event, race_number) missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entry_crew_entry_user_unique'
+  ) THEN
+    RAISE EXCEPTION 'entry_crew composite unique constraint (entry, user) missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint WHERE conname = 'entry_devices_entry_device_unique'
+  ) THEN
+    RAISE EXCEPTION 'entry_devices composite unique constraint (entry, device) missing';
+  END IF;
+
+END $$;