70e63c6aff
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.
7 lines
393 B
SQL
7 lines
393 B
SQL
DROP TABLE IF EXISTS lead_requests;
|
|
DROP FUNCTION IF EXISTS set_lead_request_reference_number();
|
|
DROP SEQUENCE IF EXISTS lead_request_number_seq;
|
|
-- tracecoin_wallets/tracecoin_ledger intentionally left in place — an
|
|
-- already-deployed migration (20260318233000_tracecoin_ledger_immutable)
|
|
-- has triggers depending on tracecoin_ledger, and other data may reference
|
|
-- these tables by now.
|