fix(tradein/estimate): не перетирать дату обращения при оживлении оценки #2828

Merged

lekss361 merged 1 commit from fix/tradein-created into main

2026-08-11 05:52:06 +00:00

lekss361 commented

2026-08-11 05:09:54 +00:00

Owner

Проблема

Оживление мёртвых оценок (#2826) копировало в оригинальную строку created_at временной строки, которую всегда создаёт estimate_quality под новым uuid.

Факт с прода: оценка ff421062-cc38-4c4c-ad2e-0cfac52d14ff создана 2026-08-10 12:54:47, после оживления created_at стал 2026-08-11 04:30:03 — попала в выборку WHERE created_at > now() - interval '10 minutes'.

created_at — дата обращения клиента, а не дата нашего пересчёта. Второй симптом того же бага: /history сортирует по created_at, поэтому оживлённая старая запись прыгала в начало списка.

Summary

created_at убран из SET в persist-UPDATE; ответ отдаёт дату исходной строки, а не временной.
revival_completed_at (миграция 256_*, идемпотентная, с lock_timeout) — отдельный аудит-след «когда успешно пересчитали». revival_attempted_at из 255_* ставится на захвате и включает проигравших троттлинг и неудачные пересчёты, поэтому переиспользовать его нельзя.
Проверены остальные поля, описывающие исходное обращение, а не результат расчёта: TTL (expires_at, retain_until), снимок входных данных (address, lat/lon, площадь, комнатность, этаж, год, тип дома, ремонт), согласие 152-ФЗ (consent, client_ip, consent_policy_version, consent_text_snapshot) — все они и раньше не входили в SET. created_at был единственным исключением.

PDF не затронут: там печатается дата формирования отчёта (dt.date.today()), а не created_at — проверено, изменений не требуется.

Test plan

Полный прогон: 4198 passed, 18 skipped (+1 новый тест, база 4197)
ruff check / ruff format — чисто, pre-commit зелёный
Новый тест: мёртвая строка со старой датой → после оживления цена новая, created_at не изменился, revival_completed_at проставлен, а expires_at/retain_until/created_by/address вообще не появляются в SET
Post-deploy: оживить запись и убедиться, что дата осталась исходной

## Проблема Оживление мёртвых оценок (#2826) копировало в оригинальную строку `created_at` **временной** строки, которую всегда создаёт `estimate_quality` под новым uuid. Факт с прода: оценка `ff421062-cc38-4c4c-ad2e-0cfac52d14ff` создана `2026-08-10 12:54:47`, после оживления `created_at` стал `2026-08-11 04:30:03` — попала в выборку `WHERE created_at > now() - interval '10 minutes'`. `created_at` — дата обращения клиента, а не дата нашего пересчёта. Второй симптом того же бага: `/history` сортирует по `created_at`, поэтому оживлённая старая запись прыгала в начало списка. ## Summary - `created_at` убран из `SET` в persist-`UPDATE`; ответ отдаёт дату исходной строки, а не временной. - **`revival_completed_at`** (миграция `256_*`, идемпотентная, с `lock_timeout`) — отдельный аудит-след «когда успешно пересчитали». `revival_attempted_at` из `255_*` ставится на захвате и включает проигравших троттлинг и неудачные пересчёты, поэтому переиспользовать его нельзя. - Проверены остальные поля, описывающие исходное обращение, а не результат расчёта: TTL (`expires_at`, `retain_until`), снимок входных данных (`address`, `lat`/`lon`, площадь, комнатность, этаж, год, тип дома, ремонт), согласие 152-ФЗ (`consent`, `client_ip`, `consent_policy_version`, `consent_text_snapshot`) — все они и раньше не входили в `SET`. `created_at` был единственным исключением. **PDF не затронут**: там печатается дата формирования отчёта (`dt.date.today()`), а не `created_at` — проверено, изменений не требуется. ## Test plan - [x] Полный прогон: **4198 passed, 18 skipped** (+1 новый тест, база 4197) - [x] `ruff check` / `ruff format` — чисто, pre-commit зелёный - [x] Новый тест: мёртвая строка со старой датой → после оживления цена новая, `created_at` не изменился, `revival_completed_at` проставлен, а `expires_at`/`retain_until`/`created_by`/`address` вообще не появляются в `SET` - [ ] Post-deploy: оживить запись и убедиться, что дата осталась исходной

lekss361 added 1 commit 2026-08-11 05:09:55 +00:00

fix(tradein/estimate): не перетирать дату обращения при оживлении оценки

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

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

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

Details

CI / changes (pull_request) Successful in 8s

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

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

Details

f5a4b8ce01

Оживление мёртвых оценок (#2826) копировало в оригинальную строку поле
created_at временной строки, которую создаёт estimate_quality. На проде
оценка ff421062, созданная 2026-08-10 12:54, после оживления получила
created_at = 2026-08-11 04:30.

created_at — дата обращения клиента, а не дата нашего пересчёта. Второй
симптом того же бага: /history сортирует по created_at, и оживлённая
старая запись прыгала в начало списка.

- created_at убран из SET в persist-UPDATE, ответ отдаёт дату исходной
  строки, а не временной
- revival_completed_at (миграция 256_*, идемпотентная) — отдельный
  аудит-след «когда успешно пересчитали»; revival_attempted_at из 255_*
  ставится на захвате и включает неудачи с троттлингом
- проверены остальные поля исходного обращения (TTL, снимок входных
  данных, согласие 152-ФЗ) — они и раньше не входили в SET

PDF не затронут: там печатается дата формирования отчёта, не created_at.