ci(tradein): гейт невалидных индексов в CI (#2990) #3150

Merged

bot-backend merged 1 commit from chore/2990-ci-invalid-index-gate into main

2026-08-27 15:54:44 +00:00

bot-backend commented

2026-08-27 15:47:36 +00:00

Collaborator

Последний невыполненный пункт acceptance #2990.

Что сделано

Запрос на pg_index.indisvalid из шага 3b deploy-tradein.yml продублирован в ci-tradein.yml — сразу после того, как гейт собрал схему из 252 миграций на чистой БД.

Почему продублирован, а не перенесён

Формулировка в issue — «перенесена из деплоя в CI». Буквальный перенос был бы регрессией: CI поднимает пустой postgres и катает миграции с нуля, и по построению не может воспроизвести оборванный CREATE INDEX CONCURRENTLY на живой базе с данными — ровно тот сценарий, ради которого проверка в деплое и появилась (#2752).

Это два разных детектора:

CI ловит миграцию, которая рождает невалидный индекс прямо из чистой схемы — на PR, до раскатки.
Деплой ловит след аварии на проде (отменённый job, ручной CIC оператором, упавший CIC с последующим IF NOT EXISTS-пропуском).

Убрать второй = снять единственную защиту от того, что описано в комментарии deploy-tradein.yml:1039-1050. Оставил оба; в CI-комментарии явно написано, кто что ловит.

Проверка

Обе ветки прогнаны verbatim на реальной базе (prod tradein-postgres):

invalid=[0]     → GATE PASSES

инвертированный предикат (WHERE i.indisvalid) — проверка ветки падения:

invalid=[358]   → GATE WOULD FAIL
 idx_lss_source_date | listing_source_snapshots
(358 rows)

Refs #2990

Последний невыполненный пункт acceptance #2990. ## Что сделано Запрос на `pg_index.indisvalid` из шага 3b `deploy-tradein.yml` продублирован в `ci-tradein.yml` — сразу после того, как гейт собрал схему из 252 миграций на чистой БД. ## Почему продублирован, а не перенесён Формулировка в issue — «перенесена из деплоя в CI». Буквальный перенос был бы регрессией: CI поднимает пустой postgres и катает миграции с нуля, и по построению **не может** воспроизвести оборванный `CREATE INDEX CONCURRENTLY` на живой базе с данными — ровно тот сценарий, ради которого проверка в деплое и появилась (#2752). Это два разных детектора: - **CI** ловит миграцию, которая рождает невалидный индекс прямо из чистой схемы — на PR, до раскатки. - **Деплой** ловит след аварии на проде (отменённый job, ручной CIC оператором, упавший CIC с последующим `IF NOT EXISTS`-пропуском). Убрать второй = снять единственную защиту от того, что описано в комментарии `deploy-tradein.yml:1039-1050`. Оставил оба; в CI-комментарии явно написано, кто что ловит. ## Проверка Обе ветки прогнаны verbatim на реальной базе (prod `tradein-postgres`): ``` invalid=[0] → GATE PASSES ``` инвертированный предикат (`WHERE i.indisvalid`) — проверка ветки падения: ``` invalid=[358] → GATE WOULD FAIL idx_lss_source_date | listing_source_snapshots (358 rows) ``` Refs #2990

bot-backend added 1 commit 2026-08-27 15:47:37 +00:00

ci(tradein): гейт невалидных индексов — деплой ловил их уже на проде

CI Trade-In / changes (pull_request) Successful in 7s

Details

CI / changes (pull_request) Successful in 10s

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Successful in 59s

Details

CI Trade-In / frontend-checks (pull_request) Successful in 1m5s

Details

CI Trade-In / backend-tests (pull_request) Successful in 4m53s

Details

4ef8bc818b

Оборванный CREATE INDEX CONCURRENTLY оставляет индекс с indisvalid=false:
планировщик им не пользуется, ошибки нет, а re-run миграции с IF NOT EXISTS
видит его как существующий и молча пропускает. До сих пор это ловил только
шаг 3b деплоя — то есть после раскатки на прод, ценой красного деплоя и
ручного DROP INDEX CONCURRENTLY в окне.

Тот же запрос теперь стоит в CI сразу после сборки схемы из 252 миграций.
Проверка в деплое ОСТАЁТСЯ: CI собирает схему с нуля и по построению не
может воспроизвести оборванный CIC на живой базе — это разные детекторы,
не дубликаты. CI ловит миграцию, которая рождает невалидный индекс из
чистой схемы; деплой ловит след аварии на проде.

Оба пути проверены на реальной базе (prod tradein-postgres): штатный
предикат → invalid=0, гейт зелёный; инвертированный → 358, ветка падения
срабатывает и печатает список idx/tbl.

Refs #2990