gendesign/backend/app
bot-backend 991e4c28ed
All checks were successful
CI Trade-In / changes (pull_request) Successful in 8s
CI / changes (pull_request) Successful in 9s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Successful in 2m21s
CI / backend-tests (pull_request) Successful in 17m15s
fix(ptica): на worker_ready зомби помечается ЛЮБОЙ 'running', а не только со снапшотом (#2464)
Докстринг _resume_zombie_runs формулирует инвариант прямо:

    No time threshold: by definition, on worker_ready ANY 'running' row is a zombie
    because there is no active worker. Previously we required heartbeat … stayed in
    'running' status forever and required manual cancel/resume.

А запрос добавлял `AND objects_snapshot IS NOT NULL`. Строка без снапшота в выборку
не попадала и оставалась 'running' НАВСЕГДА — ровно то состояние, ради устранения
которого функция и заводилась.

Снапшот нужен, но не для пометки, а для ВОЗОБНОВЛЕНИЯ: resume_kn_run восстанавливает
обход «using objects_snapshot» и без него упал бы. Поэтому зомби помечаются все, а
resume ставится только тем, кого есть чем возобновить; остальные получают честную
причину в error вместо тишины.

Про тест — отдельно, потому что первая версия была негодной. Двойник сессии отдавал
строки независимо от WHERE, и на origin/main главный тест («строка не помечена»)
ПРОХОДИЛ, а краснели два других — по ложной причине. Научил двойник соблюдать ровно
тот фильтр, о котором спор, и сузил совпадение до `AND objects_snapshot IS NOT NULL`:
правка выносит то же выражение в список полей SELECT, и совпадение по голой подстроке
отсекало бы строки у исправленной версии тоже.

Против origin/main теперь:

  строка без снапшота не помечена zombie   → падает (UPDATE вообще не выполняется)
  в смешанной выборке помечены не все      → падает: {1,3} вместо {1,2,3}
  невозобновляемому resume не ставится     — контроль, зелёный с обеих сторон
  возобновляемый получает resume как раньше — контроль, зелёный с обеих сторон

Первый контроль ловит «починку», ставящую resume всем подряд.

Замер прода 20.08: строк в 'running' сейчас нет, то есть правка предотвращает, а не
чинит. Из 20 исторических 'zombie' восемь — без objects_snapshot, так что случай
не гипотетический.

Прогоны: tests/workers rc=0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 16:51:02 +05:00
..
api fix(ptica): scope=manual_list перестаёт создавать задание из пустоты (#2464) (#2965) 2026-08-20 09:53:51 +00:00
core refactor(security): убрать мёртвую проверку админского токена (#2775) (#2776) 2026-08-07 09:30:23 +00:00
models merge: resolve conflicts with main (#1660) into week-review-finish 2026-06-17 20:21:06 +03:00
observability fix(ptica): скраб ПДн перестаёт утекать то, что защищает + проводка проверяется поведением (#2753) (#2787) 2026-08-07 10:11:36 +00:00
resources/certs feat(site-finder): ЕЭСК-резервы городских ПС/ТП + тепло из ФГИС ФАС (#2119 B2) (#2165) 2026-07-02 16:44:57 +00:00
schemas fix(site-finder): true-counts вместо молча-усечённых len(list) в connection-points/utility (#2445-A1/A2) (#2450) 2026-07-05 18:54:49 +00:00
scrapers fix(week-review): backend-аудит v2 — 82 фиксов (#1660) 2026-06-17 17:13:38 +00:00
services fix(ptica): серия WAF-блоков прерывает батч каталога, а не гонит его до конца (#2464) (#2971) 2026-08-20 10:54:11 +00:00
templates fix(site-finder): 5 дефектов из боевого фидбека analyze (#1736 #1737 #1738 #1739 #1740) 2026-06-18 11:47:21 +05:00
workers fix(ptica): на worker_ready зомби помечается ЛЮБОЙ 'running', а не только со снапшотом (#2464) 2026-08-20 16:51:02 +05:00
__init__.py init 2026-04-25 13:45:19 +03:00
main.py fix(health): не тащить HEAD-пробу в OpenAPI-схему 2026-08-15 19:22:22 +03:00