Обработчик выглядел так:
except Exception as e:
if run_id:
try:
_finish_run(db, run_id, status="failed", ...)
except Exception:
pass # ← молча
Если исходный сбой был DB-level (напр. INSERT в _save_raw), транзакция остаётся в
aborted-состоянии: _finish_run падает уже на своём execute, отказ гасится голым
pass, и строка прогона навсегда остаётся в status='running'.
Замер прода 20.08: шесть таких строк висят с 17.05 — 2274 часа, 95 суток. Уборщика
зомби для objective_scrape_runs нет (в отличие от cadastre, где он есть).
Правка: rollback перед _finish_run. Сессия здесь СВОЯ (SessionLocal() в этой же
функции, close в finally), поэтому плоский rollback законен — он отбрасывает уже
провалившуюся транзакцию и ничего чужого не теряет. Плюс отказ самого _finish_run
больше не молчит: если и после rollback не прошло, это логируется — знать об этом
важнее, чем сохранить тишину.
Тест на PostgresLikeSession — двойнике с настоящей семантикой aborted-транзакции.
На MagicMock он был бы зелёным по построению. Против origin/main:
UPDATE статуса не выполнился, журнал SQL пуст → падает
сессия закрывается в finally — контроль, зелёный с обеих сторон
исходная ошибка пробрасывается — контроль, зелёный с обеих сторон
Второй контроль не для симметрии: ловит «починку», которая заодно погасила бы
исключение — тогда Celery считал бы упавший прогон успешным.
Шесть уже висящих строк не трогаю: правка предотвращает новые, а чистка старых —
отдельное решение (данные прода, и на них ничего не завязано: с 17.05 прошёл 71
успешный прогон).
Прогоны: tests/workers — 226 passed rc=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
