avandClaude Opus 4.8
4475fbd548
Два дефекта дедуп-веток приёма (ревью Fable 2026-07-08), оба про инвариант
«≤1 активная загрузка на infohash» и сохранность источника.
F1: дедуп-ветка CreateDownloadIfNoActive дописывала все хеши входящего
источника в найденную активную задачу без пер-хеш гарда владения (в отличие
от AddInfohashes). Гибрид {v1,v2}, дедупнувшись на задачу B (владелец v2),
крал v1 у активной A → две активные владели v1. Теперь дозапись под тем же
гардом: хеш, которым владеет другая активная задача, не дописывается.
F6: при дедупе .torrent-байт на пойманную magnet-задачу (catched) байты
выбрасывались, source_type оставался magnet → worker добавлял по magnet-URL →
вечный metaDL → failed (magnet закрытого трекера без DHT метаданные не
докачает). Новый guarded-метод UpgradeCatchedMagnetToTorrent атомарно
сохраняет байты и меняет source_type magnet→torrent, но только пока задача в
catched (worker источник ещё не отдал). Ingest зовёт апгрейд на обоих
дедуп-путях. Это целевое исключение из правила спеки «при дедупе байты не
сохраняем» — оформлено MODIFIED-дельтой ingest.
Схема БД не меняется (download_torrent и source_type уже есть).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.1 KiB
Why
Ревью приёма (Fable, 2026-07-08) вскрыло два дефекта в дедуп-ветках приёма, оба про инвариант «≤1 активная загрузка на infohash» и про сохранность источника:
-
F1 — неохраняемая дозапись хешей. Дедуп-ветка
CreateDownloadIfNoActive(internal/store/download.go) безусловно дописывает ВСЕ хеши входящего источника в найденную активную задачу (INSERT OR IGNORE) без пер-хеш гарда владения — в отличие отAddInfohashes, где гард есть. Это единственная неохраняемая запись хешей, и она в авторитетном методе инварианта. Сценарий: активная A владеетv1, активная B владеетv2того же гибридного торрента; приём гибрида{v1,v2}, дедупнувшись на B, допишетv1в B → две активные владеютv1. Инвариант нарушен. -
F6 — потерянный upgrade-путь
.torrentповерх magnet. Пользователь сначала ловит magnet с закрытого трекера (задачаcatched,source_type=magnet), понимает, что без DHT метаданные не докачаются, и грузит правильный.torrent. Приём дедупит по infohash на magnet-задачу; по текущей спеке байты при дедупе НЕ сохраняются,source_typeостаётсяmagnet. Worker добавляет раздачу по magnet-URL → вечный metaDL → failed. Ровно тот артефакт, который бы починил загрузку, выбрасывается с «уже в работе».
What Changes
-
F1: дедуп-ветка
CreateDownloadIfNoActiveприменяет тот же пер-хеш гард, что иAddInfohashes: хеш, которым владеет ДРУГАЯ активная задача, не дописывается. Транзакция уже открыта — правка внутри неё. -
F6: при дедупе, где входящее — байты
.torrent, а активная задача поймана какmagnetи ещё не добавлена в qBittorrent (состояниеcatched), система сохраняет байты и меняетsource_typeнаtorrentв одной транзакции. Тогда worker добавит раздачу файлом и метаданные не придётся докачивать по DHT. Это ПРОТИВОРЕЧИТ действующему правилу спеки ingest «при дедупликации байты сохраняться SHALL NOT» — правило смягчается этим целевым исключением (MODIFIED-дельта).
Схема БД не меняется: таблица download_torrent уже есть, source_type —
существующая колонка; апгрейд — изменение данных, не структуры.
Capabilities
Modified Capabilities
ingest: уточняется поведение дедупа (пер-хеш гард дозаписи; сохранение.torrent-байт и смена источника при апгрейдеcatched-magnet).
Impact
- Код:
internal/store/download.go(гард F1 + новый guarded-метод апгрейда),internal/ingest/ingest.go(вызов апгрейда на обоих дедуп-путях). - Тесты:
internal/store,internal/ingest. - Совместимость: изменение только ужесточает инвариант (F1) и добавляет
целевой апгрейд (F6); существующие потоки без
.torrent-поверх-magnet ведут себя как прежде.