`objective_scrape_runs` не подметалась ничем: `worker_ready` знал только
про `kn_scrape_runs` и `nspd_geo_jobs`. На проде 20.08.2026 в ней висело
6 строк `status='running'` с 17.05 — 94 суток, при 71 `done` и НИ ОДНОМ
`failed`. Отсутствие `failed` — след отравления сессии, из-за которого
`_finish_run(status='failed')` не мог записаться (причина починена
#2972). Причина устранена, но жёсткое убийство воркера (редеплой, OOM)
по-прежнему оставляет `running` навсегда: у Объектива нет ни своего
cleanup_zombies, ни снапшота для resume.
Тот же инвариант, что у kn: на worker_ready активных воркеров нет,
значит любая строка `running` осиротела. Resume не ставим —
возобновлять нечего.
`finished_at` ставится НЕ NOW(), а `COALESCE(heartbeat_at, started_at)`:
прогон, умерший 94 дня назад, не должен читаться как «завершён только
что». Монитору свежести это безразлично в обе стороны — `last_success_at`
и `recent_output` считаются только по `status='done'`, а
`last_attempt_at`/`last_status` — по `started_at`, так что зомби-строки
не попадают в него ни одним столбцом (проверено по коду
_FRESHNESS_SOURCES, а не предположено).
Двусторонне: против origin/main три теста красные по существу («не
трогает objective_scrape_runs», функция при этом отрабатывает 4 запроса
— то есть краснота не от отсутствующего символа). Мутационно проверены
оба контроля: снятие `WHERE status='running'` роняет
test_only_running_rows_are_touched, замена на `finished_at = NOW()`
роняет test_finished_at_is_last_sign_of_life_not_now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
11 тасок объявляли `max_retries=2`, но ретраи не реализовывали: ни
`autoretry_for` в декораторе, ни вызова `self.retry()` в теле. Celery в
таком виде параметр не применяет — при исключении таска падает с первой
попытки. Читающий код видит «до 3 попыток», а их одна.
Убран `max_retries` у: cbr_macro_sync, rosstat_macro_sync,
developer_registry_refresh, location_refresh, mv_sales_tracker_refresh,
refresh_analytics, refresh_layout_velocity, refresh_quarter_price_index,
scrape_objective.sync_objective_group, supply_layers_refresh,
scrape_kn.scrape_kn_region. Заодно убран `bind=True` там, где `self` не
использовался вовсе; в `scrape_kn_region` он оставлен — `self.request.id`
пишется в kn_scrape_log.
Не тронуты и не должны быть: `resume_kn_run` (max_retries=12 +
настоящий self.retry()), `nspd_sync`/`scrape_cadastre` (autoretry_for),
`nspd_geo`/`objective_etl` (max_retries=0 — честное «ретраев нет»).
Гейт `test_2464_retry_config_is_real.py` разбирает AST всех модулей
`app/workers/tasks/` и требует: если декоратор объявляет ненулевой
max_retries, в нём есть autoretry_for либо в теле функции есть
self.retry(). Три таски из одиннадцати гейт нашёл сверх списка эпика.
Проверка гейта: с фиксом зелено, при возврате `max_retries=2` в
supply_layers_refresh — красно с указанием на эту таску. Плюс два
контроля: гейт видит ≥20 тасок (не молчит из-за пустой выборки) и
признаёт обе законные формы ретраев.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
create_profile/update_profile делают «снять is_default у всех → поставить новому»
двумя отдельными операторами. Между ними инвариант нарушен, и при одновременных
запросах у пользователя может оказаться ДВА профиля с is_default=TRUE. А читающий
_SELECT_DEFAULT брал LIMIT 1 БЕЗ ORDER BY — выбор молча перескакивал между ними от
запроса к запросу.
Два рубежа, а не один:
миграция 190 — частичный уникальный индекс (user_id) WHERE is_default: два
дефолта становятся невозможными на уровне БД;
ORDER BY id — детерминированный выбор, если индекс когда-нибудь снимут.
Соседние запросы этого файла тай-брейк по id уже имеют.
Индекс не мешает штатной переустановке дефолта: порядок операторов в коде уже
правильный (сначала снять у всех, потом поставить), поэтому в момент проверки
дефолтов ноль. Это отдельно проверено тестом.
Безопасность миграции: на проде нарушений нет — у admin один дефолт, у __system__
ноль, ни одного пользователя с двумя. Таблица в 4 строки, индексируется мгновенно.
lock_timeout проставлен по #2752.
Тест проверяет ПОВЕДЕНИЕ на живом Postgres: вторая установка дефолта отвергается
базой. Плюс фальсификация — без индекса два дефолта вставляются молча; без неё
зелёный тест неотличим от «оно и так не вставлялось». Плюс два контроля:
переустановка дефолта работает, разные пользователи сохраняют свои.
Тест про ORDER BY вынесен в tests/services/site_finder, а НЕ внесён в
skip_allowlist: живой БД он не требует, и пропускаться вместе с DB-тестами ему
незачем. Против origin/main он краснеет, показывая запрос без тай-брейка.
Прогоны: без БД — 648 passed rc=0; с БД — 5 passed rc=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Докстринг _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>
main принёс PR #2751 (ruff-шаг в ci-tradein.yml/backend-tests) параллельно с
fetch-depth: 0 из этой ветки в том же job'е — не противоречат друг другу,
слились автоматически.
Единственное ручное разрешение — _manifest_applied.txt (modify/delete):
main дописал файл, ветка его удаляет. Разрешение — удаление, это и есть
предмет PR: гейт номеров миграций берёт эталон из git (origin/main), а не
из ручного манифеста, который отставал и по построению не мог покраснеть
(#2683, живой инцидент 15.08 — коллизия 264_ между двумя независимыми ветками).
Review-разбор ветки fix/tradein-uptime-honest-green:
1. [HIGH] Прод-симптом `HEAD gendsgn.ru/health -> 405` обслуживает Site
Finder (Caddyfile:60 `handle /health { reverse_proxy backend:8000 }`),
а предыдущий коммит правил только tradein-mvp/backend, чей /health наружу
не проксируется вообще. Добавлен @app.head("/health") в backend/app/main.py
рядом с существующим @app.get — эмпирически подтверждено (uv run pytest):
HEAD было 405, стало 200. tradein-mvp фикс не откачен (безвреден, годится
для будущего internal-caller), но обвязан комментарием, что реальный
прод-путь чинится не там.
2. [LOW] Response(status_code=200) без media_type отдавал HEAD без
Content-Type, тогда как GET отдаёт application/json — расходится с
заявленным в комментарии RFC 9110 §9.3.2. Добавлен media_type в обоих
бэкендах; Content-Length сознательно не подгоняем под байты GET-ответа
(payload header field, RFC разрешает опускать для HEAD) — не дублируем
сборку payload ради байт-в-байт соответствия.
Тесты: test_health_head_ok_no_body добавлен в backend/tests/test_health.py
(Site Finder) — RED-check (git stash app/main.py) воспроизводит прод-баг
1:1: assert 405 == 200. tradein-mvp/backend/tests/test_health_endpoint.py
дополнен проверкой Content-Type. uv run pytest — все зелёные.
Лоадер ЕЭСК писал степень загрузки из колонки E как
`load_index = COALESCE(load_index, CAST(:load_pct AS text))`.
load_index — категориальная: 'open'|'limited'|'closed'|NULL
(data/sql/180_connection_capacity.sql:35), её заполняет
rosseti_wfs_loader._map_load_index.
Число строкой в этой колонке ломает обе стороны: фронтовый classifyLoadIndex
отбрасывает всё вне перечисления в null («неизвестно»), а
power_summary.by_load_index — словарь по значению, то есть получил бы бакет
с именем вида "41.0" рядом с open/limited/closed.
Сегодня не стреляло только потому, что load_index заполнен у всех строк
(open 2741 / limited 346 / closed 329, NULL 0 — замер верификации 13.08,
подтверждён вторым прогоном скептика), и COALESCE не проваливался. Первая же
строка с пустым индексом положила бы туда число.
Колонку E больше не читаем: места под процент в power_supply_centers нет —
load_index категориальный, current_load_mva в мегавольт-амперах.
_pct_share_to_percent оставлен с тестами, но в докстроке теперь прямо
написано, что продакшен-вызывающих у него НЕТ и при каких условиях он снова
понадобится — чтобы «код есть, эффекта нет» не выглядел работающим.
Старый тест фиксировал ровно отменяемое поведение (`first["load_pct"] == 41.0`)
— заменён на проверку, что ни SQL, ни параметры загрузку не несут. Проверять
пришлось исполняемый текст, а не прозу: слово load_index осталось в поясняющем
комментарии, и наивная проверка на подстроку падала на своём же объяснении.
Тесты двусторонние: против лоадера из main падает ровно новый.
Хунк форматирования — не мой: pre-commit ruff v0.7.4 против 0.15.12 (#2864).
Refs #2464
