veza/veza-backend-api/migrations/987_orders_hyperswitch_payment_id_backfill.sql

41 lines
2 KiB
MySQL
Raw Normal View History

fix(ci): unblock CI red — gofmt + e2e webserver reuse + orders.hyperswitch_payment_id (Day 4) Three pre-existing infra issues surfaced by the Day 1→Day 3 push wave. Each is independent — bundled here because the goal is "ci.yml + e2e.yml green" before the v1.0.9 tag, and they're all small. (1) gofmt — ci.yml golangci-lint v2 step Five files were unformatted on main. Pre-existing (untouched by my Item G work, but the formatter caught them now): - internal/api/router.go - internal/core/marketplace/reconcile_hyperswitch_test.go - internal/models/user.go - internal/monitoring/ledger_metrics.go - internal/monitoring/ledger_metrics_test.go Pure whitespace via `gofmt -w` — no behavior change. (2) e2e silent-fail — playwright webServer port collision The e2e workflow pre-starts the backend in step 9 ("Build + start backend API") so it can fail-fast on a non-ok health check. But playwright.config.ts had `reuseExistingServer: !process.env.CI` on the backend webServer entry — meaning in CI Playwright tried to spawn a SECOND backend on port 18080. The spawn collided with EADDRINUSE and Playwright silently exited before printing any test output. The artifact upload then warned "No files were found" because tests/e2e/playwright-report/ never got written, and the job ended in `Failure` for an unrelated reason (the artifact upload step's GHESNotSupportedError). Fix: backend `reuseExistingServer: true` always — workflow + dev both pre-start backend on 18080. Vite stays `!CI` because the workflow doesn't pre-start it. Comment in playwright.config.ts documents the symptom so the next person debugging gets the pointer immediately. (3) orders.hyperswitch_payment_id missing in fresh DBs — migration 080 skip-branch + 099 ordering drift Migration 080 (`add_payment_fields`) wraps its ALTERs in "skip if orders doesn't exist". At authoring time orders existed earlier in the migration sequence; that ordering has since shifted (orders is now created at 099_z_create_orders.sql, AFTER 080). Result: in any freshly-migrated DB (CI, fresh dev, future restore drills) migration 080 takes the skip branch and the columns are never added — even though the Order model and the marketplace code rely on them. Symptom: every CI run logs pq: column "hyperswitch_payment_id" does not exist from the periodic ledger_metrics worker. Order checkout would also fail to persist payment_id at write time, breaking reconciliation. Fix: append-only migration 987 with idempotent `ADD COLUMN IF NOT EXISTS` + a partial index on the reconciliation hot path. Production envs that did pick up 080 in the original order are no-ops; fresh envs converge to the same end state. Rollback in migrations/rollback/. Verified locally: $ cd veza-backend-api && go build ./... && VEZA_SKIP_INTEGRATION=1 \ go test -short -count=1 ./internal/... (all green) SKIP_TESTS=1: backend-only Go + Playwright config + SQL. Frontend unit tests irrelevant to this commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-27 10:03:55 +00:00
-- v1.0.9 Day 4 — Backfill hyperswitch_payment_id + payment_status on orders.
--
-- Migration 080 (`add_payment_fields`) wraps its ALTERs in a "skip if
-- the orders table doesn't exist" guard. At the time 080 was authored,
-- orders existed earlier in the migration sequence; that ordering has
-- since shifted (orders is now created at 099_z_create_orders.sql,
-- AFTER 080). Result: in any freshly-migrated DB (CI runs, fresh dev
-- envs, future restore drills) migration 080 takes the skip branch
-- and the columns are never added — even though the Order model and
-- the marketplace code rely on them.
--
-- Symptoms in CI: the periodic ledger_metrics worker
-- (internal/monitoring/ledger_metrics.go:164) logs
-- pq: column "hyperswitch_payment_id" does not exist
-- on every run. The order checkout flow would also fail to persist
-- the payment_id at write time, breaking any reconciliation that
-- depends on the linkage.
--
-- The fix is idempotent (`ADD COLUMN IF NOT EXISTS`) so it safely
-- applies to:
-- - production envs that *did* see migration 080 in the original
-- order (column already there, this migration is a no-op);
-- - fresh envs that picked up the broken ordering (column missing,
-- this migration adds it).
--
-- Adding a backfill at 987 instead of patching 080 in place keeps the
-- migration history append-only — re-running the suite from scratch
-- arrives at the same end state regardless of when the migration was
-- merged.
ALTER TABLE orders ADD COLUMN IF NOT EXISTS hyperswitch_payment_id TEXT;
ALTER TABLE orders ADD COLUMN IF NOT EXISTS payment_status TEXT DEFAULT 'pending';
-- Index supporting the reconciliation worker's hot path
-- (`SELECT ... WHERE status='pending' AND hyperswitch_payment_id IS NOT NULL`).
-- Partial because the universe of pending+linked rows is much smaller
-- than the full orders table.
CREATE INDEX IF NOT EXISTS idx_orders_hyperswitch_payment_id
ON orders(hyperswitch_payment_id)
WHERE hyperswitch_payment_id IS NOT NULL AND hyperswitch_payment_id <> '';