bot-backend
afa93f9a1e
All checks were successful
CI Trade-In / changes (pull_request) Successful in 8s
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / changes (pull_request) Successful in 11s
CI / backend-tests (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
CI Trade-In / backend-tests (pull_request) Successful in 4m56s
Утверждение «формула триггера = формула миграции» было ложным по ИСТОЧНИКУ базы: record_listing_price_change (131:76-86) считает процент от listings.OLD.price_rub, а не от предыдущей строки offer_price_history. Пересчёт по lag() портил честные значения: у листинга, чья история начинается с триггерной строки, lag() = NULL → −0.82 уходил в NULL; у триггерной строки с соседом-строкой загрузчика база чужая. Теперь пересчитываем и берём как базу ТОЛЬКО строки загрузчика (change_time <> recorded_at — триггер ставит обе метки одним now()). Это ровно то, что делает починенный код: процент внутри истории самой карточки. Окно lag() сужено до листингов с domklik-строками — иначе оконная функция шла по всей таблице под lock_timeout = 5s и валила деплой. Признак закреплён тестом на INSERT загрузчика (recorded_at не указан → DEFAULT NOW()); при добавлении recorded_at в INSERT тест краснеет — проверено. В шапке миграции отмечена асимметрия: старые cian-строки с |x| > 100 не чиним. |
||
|---|---|---|
| .. | ||
| app | ||
| data/sql | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| Dockerfile | ||
| pyproject.toml | ||