(low) useSiteAnalysis poll-loop: неизвестный FetchStatus молча поллится до 2-мин таймаута вместо явной ошибки #1485

New issue

Closed

opened 2026-06-15 05:57:49 +00:00 by bot-backend · 0 comments

bot-backend commented

2026-06-15 05:57:49 +00:00

Collaborator

Severity: low · Категория: logic · Файл: frontend/src/hooks/useSiteAnalysis.ts:160-213

frontend/src/hooks/useSiteAnalysis.ts:160-213. Цикл poll-status обрабатывает ready/not_in_nspd/failed/invalid_format, но не имеет ветки default/else — любой неожиданный status (опечатка бэкенда, новый/переименованный статус вроде 'pending'/'queued') попадает в неявный fall-through 'continue polling' (комментарий стр.207). Это держит пользователя в состоянии fetching до исчерпания POLL_MAX_ITERATIONS=60 (~2 мин), после чего бросается Error 'Загрузка длится слишком долго (>2 мин). Попробуйте позже.' (стр.211-213), что вводит в заблуждение (на деле — неизвестный статус, а не медленная загрузка). Импакт: только при рассинхроне фронт/бэк (FetchStatus — закрытый union из 5 значений, стр.14-19); не порча данных. Чинить: добавить явную ветку для неизвестного status — сразу бросать ошибку вида 'Неизвестный статус загрузки: ' вместо ожидания таймаута.

Почему баг: Нет ветки default/else для незнакомого FetchStatus. FetchStatus — закрытый union из 5 значений, но при рассинхроне фронт/бэк (новый статус) поведение деградирует к таймауту с вводящим в заблуждение текстом ('слишком долго' вместо 'неизвестный статус'). Не порча данных, поэтому low.

Как чинить: Добавить явную ветку: if status не один из перечисленных и не 'fetching' → throw с понятным сообщением, не продолжать цикл.

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

**Severity:** low · **Категория:** logic · **Файл:** `frontend/src/hooks/useSiteAnalysis.ts:160-213` frontend/src/hooks/useSiteAnalysis.ts:160-213. Цикл poll-status обрабатывает ready/not_in_nspd/failed/invalid_format, но не имеет ветки default/else — любой неожиданный status (опечатка бэкенда, новый/переименованный статус вроде 'pending'/'queued') попадает в неявный fall-through 'continue polling' (комментарий стр.207). Это держит пользователя в состоянии fetching до исчерпания POLL_MAX_ITERATIONS=60 (~2 мин), после чего бросается Error 'Загрузка длится слишком долго (>2 мин). Попробуйте позже.' (стр.211-213), что вводит в заблуждение (на деле — неизвестный статус, а не медленная загрузка). Импакт: только при рассинхроне фронт/бэк (FetchStatus — закрытый union из 5 значений, стр.14-19); не порча данных. Чинить: добавить явную ветку для неизвестного status — сразу бросать ошибку вида 'Неизвестный статус загрузки: <status>' вместо ожидания таймаута. **Почему баг:** Нет ветки default/else для незнакомого FetchStatus. FetchStatus — закрытый union из 5 значений, но при рассинхроне фронт/бэк (новый статус) поведение деградирует к таймауту с вводящим в заблуждение текстом ('слишком долго' вместо 'неизвестный статус'). Не порча данных, поэтому low. **Как чинить:** Добавить явную ветку: if status не один из перечисленных и не 'fetching' → throw с понятным сообщением, не продолжать цикл. --- <sub>deep-audit «армия ботов 2» · verify+harden, confidence 0.8 · unit U105</sub>