nxtgauge-backend-rust/crates/db/migrations/20260719120000_reference_numbers.down.sql
Ashwin Kumar Sivakumar 70e63c6aff fix: lead_requests table never existed, and reference_numbers migration was unconditionally broken
Tracing "can a professional send a request to contact a customer"
surfaced two more breaks in the same family as everything else fixed
this session:

1. crates/db/migrations/20260719120000_reference_numbers.up.sql (not
   yet pushed) unconditionally ran `ALTER TABLE job_applications ...`
   and `ALTER TABLE lead_requests ...`. Neither table was ever created
   by any active (non .skip) migration, so this migration would fail
   outright on a clean apply and block every migration after it in the
   chain — including all of this session's other fixes. Moved the
   reference_number column/trigger/backfill logic for job_applications
   and lead_requests into their own table-creation migrations instead,
   where the tables are guaranteed to exist.

2. lead_requests (LeadRequestRepository, send_lead_request in
   profession_shared.rs, list_requests/approve_request/reject_request
   in apps/customers/src/handlers.rs) was only ever defined in disabled
   .skip migrations, and even those didn't match the columns the
   current Rust code reads/writes (missing professional_user_id and
   reference_number; `message`/`customer_user_id`-only shape instead of
   `remarks`/`requested_at`/`resolved_at`). Added a migration with the
   schema the live code actually needs.

3. Same root cause found for tracecoin_wallets/tracecoin_ledger — only
   ever defined in .skip migrations, and with stale column names
   (`type`/`reason` vs. the `transaction_type`/`reference_type` the
   Tracecoin reservation code in TracecoinWalletRepository actually
   uses. These back the credit reservation that happens when a lead
   request is sent. Created them with CREATE TABLE IF NOT EXISTS (safe
   no-op if they already exist under any name/history) plus a
   best-effort ADD COLUMN IF NOT EXISTS fallback for the stale-name
   scenario.

NOTE: an already-deployed migration (20260318233000_tracecoin_ledger_immutable,
already on origin) creates triggers directly on tracecoin_ledger,
assuming it already exists. That migration was NOT touched here since
editing already-pushed migration history is out of scope for a blind
fix — if tracecoin_ledger doesn't already exist in the real database,
that migration has been failing since it was deployed and needs a
human to check `_sqlx_migrations` / actual schema state directly.
2026-07-21 02:00:23 +05:30

19 lines
940 B
SQL

DROP TRIGGER IF EXISTS trg_verifications_reference_number ON verifications;
DROP TRIGGER IF EXISTS trg_support_tickets_reference_number ON support_tickets;
DROP TRIGGER IF EXISTS trg_payments_reference_number ON payments;
DROP TRIGGER IF EXISTS trg_users_reference_number ON users;
DROP FUNCTION IF EXISTS set_verification_reference_number();
DROP FUNCTION IF EXISTS set_ticket_reference_number();
DROP FUNCTION IF EXISTS set_payment_reference_number();
DROP FUNCTION IF EXISTS set_user_reference_number();
ALTER TABLE verifications DROP COLUMN IF EXISTS reference_number;
ALTER TABLE support_tickets DROP COLUMN IF EXISTS reference_number;
ALTER TABLE payments DROP COLUMN IF EXISTS reference_number;
ALTER TABLE users DROP COLUMN IF EXISTS reference_number;
DROP SEQUENCE IF EXISTS verification_number_seq;
DROP SEQUENCE IF EXISTS ticket_number_seq;
DROP SEQUENCE IF EXISTS payment_number_seq;
DROP SEQUENCE IF EXISTS user_number_seq;