(low) scrape/all/page.tsx isStale: UI-порог 5 мин расходится с backend-zombie 10 мин — ложный статус «stale» у живого kn-прогона #1404

New issue

Closed

opened 2026-06-15 05:53:34 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-15 05:53:34 +00:00

Collaborator

Severity: low · Категория: logic · Файл: frontend/src/app/admin/scrape/all/page.tsx:201-207, 283

frontend/src/app/admin/scrape/all/page.tsx:201-207 (isStale), 283 (рендер статуса). isStale = status==='running' && heartbeatLag > 300 (5 минут) и подменяет отображаемый статус на «stale». Бэкенд-zombie-детектор для kn использует INTERVAL '10 minutes' (backend/app/api/v1/admin_scrape.py:100-114, комментарий «10 min без heartbeat = точно мёртв») — то есть backend ещё считает прогон running при лаге 5-9 мин, а UI уже рисует «stale». heartbeat пишется ~раз в 30с/10 объектов, и лаг 5-9 мин при долгом батче — нормальная живая работа. Импакт: ложная тревога на основном статус-индикаторе, оператор может вручную убить рабочий прогон; порчи данных нет. Замечание: scrape_cadastre.py:464 использует 5 мин, но cadastre_jobs не входит в v_scrape_runs_unified этого дашборда, так что для отображаемых тут скраперов эталон — 10 мин. Чинить: выровнять UI-порог isStale с backend (300 → 600 сек) либо вынести единую константу.

Почему баг: Расхождение порога приводит к тому, что живой kn-прогон с heartbeat-лагом 6 минут UI показывает как «stale», тогда как backend ещё считает его running и не помечает zombie. Это ложная тревога в дашборде (оператор может вручную убить рабочий прогон). Не порча данных, но вводит в заблуждение в основном статус-индикаторе.

Как чинить: Поднять фронтовый порог до 600с (совпасть с backend 10 мин для kn/nspd) или брать порог per-scraper; в идеале отображать «stale» только когда backend сам ещё не перевёл в zombie, согласовав интервалы.

_{deep-audit «армия ботов 2» · verify+harden, confidence 0.78 · unit U68}

**Severity:** low · **Категория:** logic · **Файл:** `frontend/src/app/admin/scrape/all/page.tsx:201-207, 283` frontend/src/app/admin/scrape/all/page.tsx:201-207 (isStale), 283 (рендер статуса). isStale = status==='running' && heartbeatLag > 300 (5 минут) и подменяет отображаемый статус на «stale». Бэкенд-zombie-детектор для kn использует `INTERVAL '10 minutes'` (backend/app/api/v1/admin_scrape.py:100-114, комментарий «10 min без heartbeat = точно мёртв») — то есть backend ещё считает прогон running при лаге 5-9 мин, а UI уже рисует «stale». heartbeat пишется ~раз в 30с/10 объектов, и лаг 5-9 мин при долгом батче — нормальная живая работа. Импакт: ложная тревога на основном статус-индикаторе, оператор может вручную убить рабочий прогон; порчи данных нет. Замечание: scrape_cadastre.py:464 использует 5 мин, но cadastre_jobs не входит в v_scrape_runs_unified этого дашборда, так что для отображаемых тут скраперов эталон — 10 мин. Чинить: выровнять UI-порог isStale с backend (300 → 600 сек) либо вынести единую константу. **Почему баг:** Расхождение порога приводит к тому, что живой kn-прогон с heartbeat-лагом 6 минут UI показывает как «stale», тогда как backend ещё считает его running и не помечает zombie. Это ложная тревога в дашборде (оператор может вручную убить рабочий прогон). Не порча данных, но вводит в заблуждение в основном статус-индикаторе. **Как чинить:** Поднять фронтовый порог до 600с (совпасть с backend 10 мин для kn/nspd) или брать порог per-scraper; в идеале отображать «stale» только когда backend сам ещё не перевёл в zombie, согласовав интервалы. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.78 · unit U68</sub>