Following the reference_numbers fix, audited every active (non .skip)
migration for the same failure shape — ALTER/CREATE TRIGGER against
lead_requests, tracecoin_wallets, tracecoin_ledger, or job_applications
without ever creating them — since this codebase has a repeated pattern
of table-creation migrations getting silently disabled (renamed .skip)
after the code that depends on them was already written. Found three
more, ALL already pushed to origin, meaning they've likely been
breaking the migration chain since the date each was deployed:
- 20260317195000_profession_specific_profiles.up.sql (Mar 17) — ALTERs
lead_requests twice. Earliest failure point found for the lead_requests
chain. Now self-creates a minimal lead_requests table first (no FK to
`leads`, which isn't created until June 10 — well after this migration).
- 20260318233000_tracecoin_ledger_immutable.up.sql (Mar 18) — creates
immutability triggers ON tracecoin_ledger, assuming it exists. Now
self-creates tracecoin_wallets/tracecoin_ledger first, matching the
column names (transaction_type/reference_type) the Rust code actually
uses — the only schema that ever existed for these tables (in a
disabled .skip migration) used stale names (type/reason).
- 20260425000000_ai_usage.up.sql (Apr 25) — ALTERs job_applications
inside a BEGIN/COMMIT block, so this failure was also rolling back
company_ai_usage/job_seeker_ai_usage creation in the same file. Now
self-creates job_applications first.
Each later migration that also touches these tables (this session's
customer/job-seeker/lead_requests fixes) now uses ADD COLUMN IF NOT
EXISTS instead of assuming its own CREATE TABLE ran, so the schema
converges to the same end state regardless of which migration actually
created the table first.
Every touched migration uses IF NOT EXISTS / idempotent guards
throughout, so this is safe to apply whether or not any of these tables
already exist in the real database.
94a8a1096a