5ce95a28a8
All checks were successful
CI Trade-In / browser-tests (pull_request) Has been skipped
CI / backend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
CI Trade-In / changes (pull_request) Successful in 8s
CI / changes (pull_request) Successful in 9s
CI / frontend-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Successful in 1m1s
CI Trade-In / backend-tests (pull_request) Successful in 4m1s
check-migration-lock-timeout.py требует lock_timeout только для NN >= 250 в tradein — порог назначен по номеру аварийной миграции 250, которую затем сняли с деплоя (#2792). Фактический максимум применённого на main — 239, то есть весь диапазон 240-249 гейтом не проверяется вообще ("проверено новых миграций: 0" = не проверено ни одного файла, не "все чисты"). Функция scan() из самого гейта, прогнанная напрямую без порогового отсечения, помечает ALTER TABLE в этом файле как блокирующий DDL без lock_timeout. trade_in_estimates — самая горячая таблица стека (история, история сотрудников, каждое чтение/PDF оценки); на этой БД уже наблюдались открытые транзакции на 46 и 22 часа. Ждущая ACCESS EXCLUSIVE-блокировка встаёт в очередь перед новыми запросами приложения. DDL на 1058 строках мгновенный — риск не в исполнении, а в ожидании чужой блокировки. Добавлено SET LOCAL lock_timeout = '5s' сразу после BEGIN + объяснение в шапке файла, почему оно здесь при том что гейт формально не требует — чтобы не убрали как "лишнее". Порог гейта не трогаю — отдельный issue. |
||
|---|---|---|
| .. | ||
| app | ||
| data/sql | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| Dockerfile | ||
| pyproject.toml | ||