fix(tradein): 095 drop v_data_quality before dropping sale_type_text — RED deploy (#731) #903

Merged

lekss361 merged 1 commit from fix/731-sale-type-text-view-dep into main

2026-05-31 14:02:01 +00:00

bot-backend commented

2026-05-31 13:57:50 +00:00

Collaborator

🔴 Hotfix — prod deploy is currently RED

The 2026-05-31 13:50 deploy failed applying migration 095:

ERROR: cannot drop column sale_type_text of table listings because other objects depend on it
DETAIL: view v_data_quality depends on column sale_type_text of table listings
FAILED on migration: 095_dead_schema.sql → exit 1

This aborts the deploy → migrations 095, 096, 097 are NOT applied on prod (only 092–094 are). The demo-critical 094 (cadastral_unify) applied fine earlier; nothing demo-blocking is broken, but the deploy pipeline is stuck red until 095 is fixed.

Root cause

v_data_quality (recreated in 094) has a CTE SELECT * FROM listings. Postgres records a column-level dependency on every listings column from SELECT * — including sale_type_text — even though it's not an output column. So a bare ALTER TABLE listings DROP COLUMN sale_type_text is blocked. The original #731 spec caught the 2 code refs but missed this view dep (same class of trap as #732).

Fix

DROP VIEW v_data_quality → DROP COLUMN sale_type_text → recreate the view with the identical 094 DDL (after the column is gone, SELECT * simply no longer includes it). Verified v_data_quality is the only object doing SELECT * FROM listings (listings_search_mv and v_price_divergence use explicit columns) → no second dependency will surface.

Why edit the merged 095 in place

095 never applied on prod (BEGIN…ERROR → transaction rolled back atomically; it's not in _schema_migrations). The runner re-runs the corrected file on the next deploy. A new 098 would NOT work — the runner hits 095 first and keeps failing.

Test plan

DDL traced: v_data_quality 094 def has no sale_type_text output; grep confirms only it does SELECT * FROM listings. Idempotent (DROP … IF EXISTS + CREATE OR REPLACE).
Merge → redeploy → verify: _schema_migrations now contains 095/096/097; SELECT 1 FROM v_data_quality ok; information_schema.columns has no listings.sale_type_text.

Please merge ASAP to unblock the deploy. Refs #731

## 🔴 Hotfix — prod deploy is currently RED The 2026-05-31 13:50 deploy failed applying migration **095**: ``` ERROR: cannot drop column sale_type_text of table listings because other objects depend on it DETAIL: view v_data_quality depends on column sale_type_text of table listings FAILED on migration: 095_dead_schema.sql → exit 1 ``` This aborts the deploy → migrations **095, 096, 097 are NOT applied** on prod (only 092–094 are). The demo-critical 094 (cadastral_unify) applied fine earlier; nothing demo-blocking is broken, but the deploy pipeline is stuck red until 095 is fixed. ## Root cause `v_data_quality` (recreated in 094) has a CTE `SELECT * FROM listings`. Postgres records a **column-level dependency on every listings column** from `SELECT *` — including `sale_type_text` — even though it's not an output column. So a bare `ALTER TABLE listings DROP COLUMN sale_type_text` is blocked. The original #731 spec caught the 2 code refs but missed this view dep (same class of trap as #732). ## Fix `DROP VIEW v_data_quality` → `DROP COLUMN sale_type_text` → recreate the view with the **identical 094 DDL** (after the column is gone, `SELECT *` simply no longer includes it). Verified `v_data_quality` is the **only** object doing `SELECT * FROM listings` (`listings_search_mv` and `v_price_divergence` use explicit columns) → no second dependency will surface. ## Why edit the merged 095 in place 095 **never applied** on prod (BEGIN…ERROR → transaction rolled back atomically; it's not in `_schema_migrations`). The runner re-runs the corrected file on the next deploy. A new `098` would NOT work — the runner hits 095 first and keeps failing. ## Test plan - [x] DDL traced: `v_data_quality` 094 def has no `sale_type_text` output; grep confirms only it does `SELECT * FROM listings`. Idempotent (`DROP … IF EXISTS` + `CREATE OR REPLACE`). - [ ] **Merge → redeploy → verify:** `_schema_migrations` now contains 095/096/097; `SELECT 1 FROM v_data_quality` ok; `information_schema.columns` has no `listings.sale_type_text`. **Please merge ASAP** to unblock the deploy. Refs #731

bot-backend added 1 commit 2026-05-31 13:57:50 +00:00

fix(tradein): 095 drop v_data_quality before dropping sale_type_text (#731 ) 5d6238e89a

Prod deploy 2026-05-31 13:50 failed on 095: 'cannot drop column sale_type_text
of table listings because view v_data_quality depends on it'. The view (recreated
in 094) has a CTE 'SELECT * FROM listings' which records a column-level dependency
on EVERY listings column incl sale_type_text — so the bare DROP COLUMN aborts the
whole migration (exit 1), blocking 095/096/097 from applying.

Fix: DROP VIEW v_data_quality -> DROP COLUMN sale_type_text -> recreate the view
with the identical 094 DDL (sale_type_text was never an output column, only pulled
in implicitly via SELECT *; after the drop, * no longer includes it). Verified
v_data_quality is the only object doing SELECT * FROM listings — listings_search_mv
and v_price_divergence reference explicit columns, so no other dependency blocks.

095 never applied on prod (transaction rolled back atomically, not in
_schema_migrations) → next deploy re-runs the corrected file. Editing the merged
migration in place is the correct recovery (a new 098 would not help: the runner
hits 095 first and keeps failing).

Refs #731