fix(deploy-tradein): track SQL migrations with _schema_migrations + baseline #637

Merged

Light1YT merged 1 commit from fix/tradein-migration-tracking into main

2026-05-29 06:34:02 +00:00

Light1YT commented

2026-05-29 06:32:11 +00:00

Owner

Summary

Fixes H1 — the root cause of the 2026-05-28 verification-debt incident («не знаем, наложились ли миграции»).

deploy-tradein.yml applied migrations with psql ... < file || echo "(skipped — already applied or error)":

No tracking — every .sql re-ran on every deploy.
Swallowed errors — a failed migration looked like success → deploy continued on a broken schema.

Ports the proven _schema_migrations pattern from the main deploy.yml (skip-if-applied + || { echo FAILED; exit 1; }), adapted for -p gendesign-tradein / psql -U tradein -d tradein / backend/data/sql/. Adds a first-run baseline: when the tracking table doesn't pre-exist, all current filenames are seeded as already-applied WITHOUT running them — prod is live on 001-076 and 7 of those carry non-idempotent INSERT seeds (002/003/052/053/054/063/072) that would PK-violate under the new strict gate.

Reviewed by code-reviewer: ✅ approve, no blockers (port is faithful; the added tr -d trim makes it more robust than the reference against trailing CR from exec -T).

Caveat (documented)

The first deploy seeds 001-076 as baseline (not executed). Do not bundle a brand-new migration in the very same push that introduces _schema_migrations — it would be marked applied without running. This PR ships zero .sql, so the condition is already satisfied; once tracking exists the baseline never re-fires.

Test plan

YAML parses (yaml.safe_load)
Bash traced under set -euo pipefail: baseline path / steady-state new-migration / failing-migration → exit 1
Ordering preserved: up -d → migrate → restart tradein-backend (FDW hook, PR #493)
Post-merge: deploy log shows baseline fired once + ✓ Already applied for 001-076; then qa-tester smoke on tradein routes

Closes #636

## Summary Fixes **H1** — the root cause of the 2026-05-28 verification-debt incident («не знаем, наложились ли миграции»). `deploy-tradein.yml` applied migrations with `psql ... < file || echo "(skipped — already applied or error)"`: 1. **No tracking** — every `.sql` re-ran on every deploy. 2. **Swallowed errors** — a failed migration looked like success → deploy continued on a broken schema. Ports the proven `_schema_migrations` pattern from the main `deploy.yml` (skip-if-applied + `|| { echo FAILED; exit 1; }`), adapted for `-p gendesign-tradein` / `psql -U tradein -d tradein` / `backend/data/sql/`. Adds a **first-run baseline**: when the tracking table doesn't pre-exist, all current filenames are seeded as already-applied WITHOUT running them — prod is live on 001-076 and 7 of those carry non-idempotent INSERT seeds (002/003/052/053/054/063/072) that would PK-violate under the new strict gate. Reviewed by code-reviewer: ✅ approve, no blockers (port is faithful; the added `tr -d` trim makes it _more_ robust than the reference against trailing CR from `exec -T`). ## Caveat (documented) The first deploy seeds 001-076 as baseline (not executed). **Do not bundle a brand-new migration in the very same push that introduces `_schema_migrations`** — it would be marked applied without running. This PR ships **zero** `.sql`, so the condition is already satisfied; once tracking exists the baseline never re-fires. ## Test plan - [x] YAML parses (`yaml.safe_load`) - [x] Bash traced under `set -euo pipefail`: baseline path / steady-state new-migration / failing-migration → `exit 1` - [x] Ordering preserved: `up -d` → migrate → `restart tradein-backend` (FDW hook, PR #493) - [ ] Post-merge: deploy log shows baseline fired once + `✓ Already applied` for 001-076; then qa-tester smoke on tradein routes Closes #636

Light1YT added 1 commit 2026-05-29 06:32:12 +00:00

fix(deploy-tradein): track SQL migrations with _schema_migrations + baseline 629f81db77

The tradein deploy re-ran every data/sql/*.sql on every deploy and
swallowed failures via `|| echo "(skipped...)"`, so a genuinely failed
migration was reported as success and the deploy continued on a broken
schema — root cause of the verification-debt incident (H1).

Port the proven _schema_migrations tracking pattern from deploy.yml:
apply each migration exactly once; on failure `exit 1` instead of
swallowing. Add a first-run baseline — when the tracking table does not
pre-exist, seed all current filenames as already-applied WITHOUT running
them, so the live 001-076 schema (7 migrations carry non-idempotent
INSERT seeds) is not re-executed under the new strict ON_ERROR_STOP gate.

Migration block keeps its load-bearing position (after `up -d`, before
the tradein-backend restart that retries the FDW USER MAPPING hook,
PR #493). No --single-transaction (3 migrations use CREATE INDEX
CONCURRENTLY).

Closes #636