Exact

Exact Union RegExp

bot-backend a7362bc5fa fix(#3391): пульс не пишет по финализированной строке; отмена в теле тика тоже помечает; rollback/try/честный лог ... Пять замечаний deep-ревью к PR #3392, ровно они. 1. Пульс стирал метку дрейна. `update_heartbeat` обеих копий бил `WHERE id = :run_id` без гейта по статусу, а app-копия counters ЗАМЕНЯЕТ (#3390): задача, помеченная `interrupted`, но ещё живая (ветка таймаута drain_inflight отдаёт её внешнему hard-cancel'у — несколько итераций спустя, пульс на каждый батч — app/services/scheduler.py:141), следующим же ударом стирала метку, и оборванный прогон снова читался как полный проход. Гейт — `IN ('running', 'cancelled')`, а не `= 'running'`: 'cancelled' финализирует строку, но задача встаёт лишь на ближайшей границе якоря, и её последний пульс — ЕДИНСТВЕННЫЙ писатель чекпоинта в этот момент (pipeline.py:1308/2368/2986/4488, mark_done там уже no-op по своему гейту), а 'cancelled' входит в _RESUME_STATUSES — сужение до 'running' молча съело бы точку возобновления у каждой отмены. Возвращаемое значение update_heartbeat не читает никто (обе копии -> None, ни одного присваивания на 130 сайтах вызова), так что «0 строк обновлено» ломать нечего; no-op логируется WARNING'ом, как у mark_done. 2. Отмена вне drain_inflight. Hard-cancel приходит по расписанию grace'а scheduler_main, а не по нашему, и может застать ТЕЛО тика (reap / stale-digest / `_dispatch` с сетевым pre_claim). `except Exception` тика CancelledError не ловит, до `await ctx.drain_inflight()` дело не доходит — строки оставались 'running'. Тело вынесено в `_tick_loop`, `scheduler_loop` ловит CancelledError, помечает in-flight и пробрасывает отмену. 3. rollback в except пометки: отказавший statement оставляет сессию в aborted-tx, и первый же непроходимый run_id утаскивал все следующие (образец — defensive rollback в mark_failed/mark_banned). 4. session_factory()/db.close() втянуты в try: исключение оттуда ЗАМЕНИЛО бы собой CancelledError, а suppress(CancelledError) в scheduler_main его не глушит — процесс уходил бы с трейсбеком вместо чистого drain-выхода. 5. WARNING перечисляет marked_ids, а не весь run_ids (там были и пропущенные по статусу). В докстринге назван потолок: SELECT синхронный, у движка нет ни connect-, ни statement-таймаута (app/core/db.py:8-19) — недоступная БД блокирует луп до SIGKILL'а через 20 с docker-grace; данные при этом не хуже прежних (строки остаются 'running' → boot-reap). Тесты — по значению, не по факту вызова; на исходниках 30e3bacc краснеют все пять: 'listings_processed' дописан в финализированную строку (kit), KeyError: 'interrupted' (app), assert 'running' == 'done' (отмена в теле тика), assert 0 == 1 (второй run_id не помечен после отказа первого), RuntimeError наружу (недоступная БД).		2026-09-06 09:03:56 +05:00
..
scraper-kit	fix(#3391): пульс не пишет по финализированной строке; отмена в теле тика тоже помечает; rollback/try/честный лог	2026-09-06 09:03:56 +05:00