Приём: пропажа источника у активной загрузки → failed(source_gone) (MAJOR-3)

Раздача активной (downloading) загрузки, исчезнувшая из qBittorrent (удалил пользователь/другой клиент), делала задачу вечным зомби: поллинг промахивался по torrentFor, писал Warn и continue каждый тик — состояние не менялось, уведомления и телеметрии не было, checkTimeouts без торрента не срабатывал. Пропажей источника у downloading не владел никто (сверка рассинхрона покрывает только done/target_missing/orphaned, восстановление — failed/stuck). Активный цикл Poll теперь применяет тот же дебаунс пропажи источника, что и сверка рассинхрона (source_miss_count / source_missing_threshold): после порога подряд идущих промахов задача уходит downloading → failed с distinct error_code source_gone и уведомлением. До порога транзиентная недоступность qBit (рестарт демона) задачу не роняет. source_gone восстановлению сверкой не подлежит (удаление намеренно), но штатно retriable — Retry заново отдаёт сохранённый источник; Retry сбрасывает source_miss_count, чтобы вернувшаяся задача получила полное грейс-окно, а не упала снова на ближайшем тике. Ребро downloading → failed уже было в графе, миграций/полей БД нет. Спека download-tracking дополнена требованием, диаграмма workflow.md — ребром. Change downloading-source-gone заархивирован. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 18:05:04 +03:00
parent bfd469bd43
commit 2a5a65f2d5
13 changed files with 524 additions and 21 deletions
@@ -21,7 +21,6 @@ Tududi (проект `jellybit`) больше **не** держит беклог
 - [Полное удаление загрузки из jellybit («единое окно», path 2)](udalenie-edinoe-okno.md) — Действие «Удалить»: снять хардлинки + снести раздачу+файлы из qBittorrent → освободить место (отдельно от undo)
 - [Ретеншн и очистка БД](retention-ochistka-bd.md) — Терминальные задачи (done/cancelled/failed/reverted), их попытки recognition с сырыми…
 - [Eval-харнес распознавания (корпус кейсов + метрика точности)](eval-harness-raspoznavaniya.md) — Распознавание — ядро продукта, но смена модели или правка промпта сейчас вслепую…
- [Восстановление zombie downloading при пропаже источника из qBittorrent (MAJOR-3)](review-major3-zombie-downloading.md) — торрент пропал из qBittorrent в downloading → задача вечный зомби, никто не двигает _(ревью 2026-07-08)_

 ## Средний

@@ -1,11 +0,0 @@
-# Восстановление zombie downloading при пропаже источника из qBittorrent (MAJOR-3)
-
-**Приоритет:** высокий · **Теги:** review-2026-07-08, lifecycle
-
-Ревью Fable 2026-07-08 (жизненный цикл). worker.go:472-477. Подтверждено чтением кода.
-
-Сценарий: торрент удалён из qBittorrent (юзером/другим клиентом), пока задача в downloading. Poll: torrentFor промах → Warn «active download not found in qbittorrent» → continue. Каждый тик, вечно. reconcileDesync покрывает только done/target_missing/orphaned; reconcileRecovery — failed/stuck; дебаунса для этого случая НЕТ, состояние не меняется, уведомления нет, checkTimeouts требует торрент. Задача — вечный зомби, активна в UI без телеметрии; выход только Cancel/Defer. Тот же зомби при провале отката Retry (worker.go:716-729). Спека намеренно исключает активные из матрицы source×target, но «источник исчез в downloading» не владеет НИКТО — дыра спеки (сравн.: та же пропажа в completed/recognizing деградирует штатно).
-
-Фикс: расширить дебаунс пропажи источника (SourceMissCount) на downloading → после порога downloading→deleted (или failed с distinct error_code для re-Add) + уведомление. Нужно ребро графа.
-
-Вердикт: полноценный change. Классический «застрявшее состояние, которое никто не двигает».
@@ -22,6 +22,7 @@ stateDiagram-v2
    downloading --> completed: файлы на месте
    downloading --> stuck: stalledDL дольше stuck_after
    downloading --> failed: metaDL дольше magnet_timeout (страховка) / error
+    downloading --> failed: источник пропал из qBittorrent (source_gone, после дебаунса)

    completed --> recognizing

@@ -170,6 +171,13 @@ SQLite; `worker` периодически сверяет qBittorrent с БД и
  в `downloading` не ронял задачу снова на ближайшем тике.
 - **ошибка:** `error`/`missingFiles` → `failed` (`error_code` `qbit_error`) —
  это настоящий провал, в отличие от таймаута.
+- **источник пропал:** раздача активной загрузки устойчиво (после дебаунса
+  `source_missing_threshold`, тот же счётчик, что и сверка рассинхрона) исчезла
+  из qBittorrent (удалил пользователь/другой клиент) → `failed` (`error_code`
+  `source_gone`). Иначе `downloading` без раздачи оставался бы вечным зомби,
+  которого никто не двигает (MAJOR-3). В отличие от таймаутов, сверка
+  `source_gone` **не воскрешает** (удаление намеренно) — но задача штатно
+  retriable: `Retry` заново отдаёт сохранённый источник.

 ### Уведомление и восстановление

@@ -184,7 +192,8 @@ SQLite; `worker` периодически сверяет qBittorrent с БД и
  только источник в qBittorrent ожил и продвинулся за условие падения
  (получил метаданные → `downloading`; уже готов → `completed`). Пока торрент
  всё ещё в `metaDL`/`stalledDL`, задача остаётся упавшей (без зацикливания).
-  Настоящие провалы (`qbit_error`) сверкой не воскрешаются.
+  Настоящие провалы (`qbit_error`) и намеренная пропажа источника
+  (`source_gone`) сверкой не воскрешаются — только ручной retry.
 - Дополнительно доступен **ручной retry** из веб-UI и Telegram (не только
  REST): возвращает в `downloading`, перецепляясь к живому **здоровому** торренту
  без повторного `Add` (к сломанному — `error`/`missingFiles` — не