fix(tradein): откат транзакции в backfill + неотрицательный счётчик квот #2538

Merged

lekss361 merged 1 commit from fix/tradein-audit-backfill-quota into main

2026-07-26 22:21:09 +00:00

Author	SHA1	Message	Date
bot-backend	9c59586be6	fix(tradein/backfill): rollback on listings save failure + nonnegative used quota All checks were successful CI / changes (pull_request) Successful in 8s Details CI Trade-In / changes (pull_request) Successful in 9s Details CI Trade-In / frontend-checks (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 / openapi-codegen-check (pull_request) Has been skipped Details CI Trade-In / backend-tests (pull_request) Successful in 4m57s Details 1. cian_history_backfill.py listings block was missing the same db.rollback() the houses block already has: save_detail_enrichment() runs several unprotected db.execute() and only commits at the end. A single bad row (e.g. a non-standard Cian change_time hitting CAST(:ct AS timestamptz)) leaves the session in a failed-transaction state, and every subsequent listing in the batch (up to 49) then fails with PendingRollbackError -- one real failure looked like N independent ones in the logs. 2. account_estimate_usage.used had no floor. Prod audit: praktika 2026-06 shows used=-3 against 42 real estimates. Migration 185 already fixed this class of bug for user2 (negative used from a retired SQL-runbook bonus hack) but only reset that one username. No decrement path exists anywhere in app.services.account_quota -- increment() only ever does used+1 under a WHERE used < lim guard (#747) -- so the minus is external (manual UPDATE), not an app bug. Migration 189 resets all remaining negative used rows and adds CHECK (used >= 0) so a future manual UPDATE can't reintroduce it.	2026-07-27 00:30:52 +03:00

Author

SHA1

Message

Date

bot-backend

9c59586be6

fix(tradein/backfill): rollback on listings save failure + nonnegative used quota

CI / changes (pull_request) Successful in 8s

Details

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

Details

CI Trade-In / frontend-checks (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 / openapi-codegen-check (pull_request) Has been skipped

Details

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

Details

1. cian_history_backfill.py listings block was missing the same
   db.rollback() the houses block already has: save_detail_enrichment()
   runs several unprotected db.execute() and only commits at the end.
   A single bad row (e.g. a non-standard Cian change_time hitting
   CAST(:ct AS timestamptz)) leaves the session in a failed-transaction
   state, and every subsequent listing in the batch (up to 49) then
   fails with PendingRollbackError -- one real failure looked like N
   independent ones in the logs.

2. account_estimate_usage.used had no floor. Prod audit: praktika
   2026-06 shows used=-3 against 42 real estimates. Migration 185
   already fixed this class of bug for user2 (negative used from a
   retired SQL-runbook bonus hack) but only reset that one username.
   No decrement path exists anywhere in app.services.account_quota --
   increment() only ever does used+1 under a WHERE used < lim guard
   (#747) -- so the minus is external (manual UPDATE), not an app bug.
   Migration 189 resets all remaining negative used rows and adds
   CHECK (used >= 0) so a future manual UPDATE can't reintroduce it.

2026-07-27 00:30:52 +03:00