3f326e8266
Some checks failed
Veza CI / Rust (Stream Server) (push) Successful in 4m22s
Security Scan / Secret Scanning (gitleaks) (push) Successful in 1m5s
Veza CI / Frontend (Web) (push) Failing after 17m19s
E2E Playwright / e2e (full) (push) Failing after 20m28s
Veza CI / Backend (Go) (push) Successful in 21m31s
Veza CI / Notify on failure (push) Successful in 4s
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>
40 lines
2 KiB
SQL
40 lines
2 KiB
SQL
-- 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 <> '';
|