Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
Why
Retry задачи в failed/stuck, чей торрент ЖИВ в qBittorrent, но в состоянии
ошибки (error/missingFiles), сейчас повторно отдаёт источник. На живом
сломанном торренте это бесполезно: qBittorrent отвергает дубль, задача уходит в
downloading, а на ближайшем тике сверки classErrored тут же возвращает её в
failed (+ дебаунс уведомления). Пользователю retry выглядит сломанным, а
реальное лекарство (перепроверка/recheck/восстановление файлов в qBittorrent)
не подсказано (находка ревью NIT-12).
What Changes
- Retry сломанного живого торрента отклоняется, а не переотдаёт источник.
Отказ несёт понятное сообщение: починить раздачу (
recheck/восстановить файлы) в qBittorrent и повторить. Состояние задачи не меняется, повторногоAddне происходит. - Повторный
Addпри retry остаётся только для случая, когда раздачи в qBittorrent НЕТ (перецепка к здоровому живому торренту — безAdd, как и раньше).
Capabilities
New Capabilities
Нет.
Modified Capabilities
state-reconciliation: требование «Ручной повтор зависшей/упавшей загрузки из транспортов» — ветка живого сломанного торрента меняет исход с «повторно отдать источник» на «отклонить с подсказкой проrecheck». Прочие ветки retry (нет раздачи →Add; жив и здоров → перецепка безAdd; сброс базисаretried_at) без изменений.
Impact
- Спеки: дельта
state-reconciliation(одно MODIFIED-требование). - Код:
internal/worker/worker.go—Retry(веткаalive && classErrored→ отказErrConflictс сообщением вместоreAdd). - Тесты:
internal/worker/worker_test.go— отклонение retry на живом сломанном торренте (error/missingFiles), контроль перецепки здорового. - Миграции БД: нет.