Раздача активной (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>
3.6 KiB
Пропажа источника у активной загрузки (MAJOR-3)
Why
Если раздача исчезает из qBittorrent (пользователь или другой клиент удалил её),
пока задача в downloading, задача становится вечным зомби. Поллинг активных
загрузок промахивается по torrentFor, пишет Warn "active download not found in qbittorrent" и делает continue — и так каждый тик, бесконечно. Состояние не
меняется, уведомления нет, телеметрии нет, checkTimeouts требует торрент (значит
таймауты-предохранители не срабатывают). Единственный выход — ручной Cancel/Defer.
Дыра: сверка рассинхрона (state-reconciliation) покрывает пропажу источника
только для уже разложенных состояний (done/target_missing/orphaned), а
восстановление (reconcileRecovery) — только failed/stuck. Для активного
downloading пропажей источника не владеет НИКТО. Сравни: та же пропажа в
completed/recognizing/review деградирует штатно (там источник уже не нужен
или его отсутствие ведёт через матрицу).
What Changes
- Поллинг активных загрузок SHALL применять дебаунс пропажи источника (тот же
SourceMissCount/[worker].source_missing_threshold, что и сверка рассинхрона): промахtorrentForнаращивает счётчик, любое появление раздачи его сбрасывает. - После порога подряд идущих промахов задача SHALL переходить
downloading → failedс новым отдельнымerror_codesource_goneи уведомлять автора (EventFailed). source_goneвосстановлению сверкой не подлежит (не входит в наборreconcileRecovery): удаление источника из qBittorrent — намеренное действие, молча воскрешать задачу нельзя. Задача остаётся штатно retriable:Retryзаново отдаёт источник (у нас сохранены magnet/.torrent-байты).
Ребро графа downloading → failed уже объявлено — нового ребра не требуется.
Меняется только набор error_code и поведение поллинга активных загрузок.
Capabilities
download-tracking— ADDED: «Пропажа источника у активной загрузки».
Impact
- Код:
internal/worker/worker.go(поллинг активных загрузок, новыйerrCodeSourceGone), тесты воркера. - Спека:
download-tracking(новое требование). Диаграммаdocs/specs/workflow.md(миррор FSM) — добавить реброdownloading → failed (source_gone). - Миграции БД нет:
source_miss_countуже существует, новых полей не вводим. - Конфиг без изменений: переиспользуем
source_missing_threshold.