Files

T

Идентичность на ULID: download_infohash, guarded-дедуп, миграция (ulid-identity)

Все сущности переехали с INTEGER AUTOINCREMENT на TEXT ULID (lowercase,
internal/ident — единая точка генерации и разбора; oklog/ulid). Инфохэши
загрузки — множество (download_infohash, v1/v2 гибридных торрентов): дедуп
и сопоставление в поллинге по любому из хешей, magnet-парсер отдаёт оба
хеша гибридной ссылки, усечённый v2-хеш v2-only раздач не хранится.

Инвариант «не более одной активной загрузки на infohash» вместо снятого
unique-индекса держат guarded-методы store в одной write-транзакции
(_txlock=immediate): CreateDownloadIfNoActive (приём/adopt, с доносом
недостающих хешей), ActivateIfNoOtherActive (retry/recovery/relink, отказ
до побочных эффектов), guarded AddInfohashes; SetDownloadState отклоняет
терминал→активное как механический бэкстоп.

Миграция 0006 — первая Go-миграция goose: пересоздание таблиц при
включённых FK, backfill ULID с timestamp из created_at (хронология id
сохранена), разнос infohash, удаление idempotency_key. BREAKING: формат id
в URL/логах/Telegram, REST-поля id (string) и infohashes (список).

Новая конвенция docs/conventions/database.md (без числовых PK), корреляция
в логах grep'ом по голому ULID, ER-схема обновлена. Спеки: новая capability
identity, MODIFIED в state-reconciliation; change заархивирован. Пройдены
ревью дизайна и кода (по 8 углов), все находки исправлены с
регрессионными тестами.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-02 21:25:00 +03:00

8.4 KiB

Raw Permalink Blame History

state-reconciliation — дельта для ulid-identity

Механика идемпотентности меняется: снимаемый/восстанавливаемый idempotency_key исчезает, инвариант «не более одной активной задачи на infohash» обеспечивается проверкой активности по download_infohash (см. capability identity).

MODIFIED Requirements

Requirement: Периодическая сверка состояния с реальностью

worker SHALL периодически (на тике поллинга) сверять задачи, для которых ожидаются разложенные файлы, с фактом на файловой системе и в qBittorrent, и выводить состояние задачи из двух независимых признаков: присутствия источника (раздача, совпавшая с любым из известных хешей загрузки в download_infohash, в выдаче qBittorrent) и присутствия цели (см. требование о владении целевым путём: существуют все ссылки последнего батча со статусом раскладки, всё ещё принадлежащие этой загрузке).

Сверке по матрице «источник × цель» SHALL подвергаться состояния done, target_missing, orphaned. Состояние deleted сверка трогать SHALL NOT — оно терминально. Активные (downloading/recognizing/review/deferred/ linking) и пользовательски-терминальные (reverted/cancelled) состояния сверка по матрице трогать SHALL NOT.

Восстановимые failed/stuck (с error_code magnet_timeout или stalled — задержки, вызванные нашей нетерпеливостью, а не реальной ошибкой) сверка SHALL рассматривать отдельно — на предмет оживления источника (см. требование о восстановлении зависшей загрузки), не по матрице «источник × цель». Прочие failed (например qbit_error) сверка трогать SHALL NOT.

Состояние SHALL переписываться только при его изменении (без записи и логов, когда выведенное состояние совпадает с текущим).

Scenario: Источник и цель на месте — состояние не меняется

WHEN для задачи в done раздача присутствует в qBittorrent и все её разложенные хардлинки существуют
THEN задача остаётся в done
AND запись состояния и лог перехода не выполняются

Scenario: Частичная пропажа цели считается отсутствием

WHEN часть разложенных хардлинков задачи удалена, а источник на месте
THEN цель считается отсутствующей и задача переходит в target_missing

Scenario: Задача в deleted сверкой не переоценивается

WHEN задача находится в deleted
THEN сверка её не рассматривает и состояние не меняет, даже если по её бывшему пути появился файл другой загрузки

Scenario: Провал по ошибке qBittorrent восстановлению не подлежит

WHEN задача в failed с error_code qbit_error
THEN сверка её не рассматривает и состояние не меняет

Requirement: Восстановление зависшей загрузки при оживлении источника

Система SHALL возвращать в активный поток задачу, упавшую из-за нашей нетерпеливости (failed/magnet_timeout или stuck/stalled), если её источник в qBittorrent жив и продвинулся: переход выводится из текущего состояния торрента так же, как при штатной сверке загрузки (uploading/stalledUP/… → completed; downloading/metaDL/… → downloading). Восстановление SHALL опираться на фактическое состояние торрента в qBittorrent, а не на время с момента создания записи.

После возврата в любое нетерминальное состояние (downloading или completed) повторный приём того же infohash SHALL снова дедуплицироваться на эту задачу: активность задачи выводится только из её state, отдельный восстанавливаемый ключ идемпотентности отсутствует. Если за время простоя в failed/stuck тем же infohash (любым из хешей задачи) уже завладела другая активная задача (новый приём, пока эта лежала упавшей), система SHALL NOT воскрешать упавшую задачу и SHALL оставить её в failed/stuck, сохраняя инвариант «не более одной активной задачи на infohash».

magnet_timeout/stalled SHALL быть редким страховочным исходом, а не рабочим механизмом: пока торрент в metaDL/forcedMetaDL или иным образом прогрессирует в пределах страховочного таймаута, задача в failed/stuck из-за него оказаться SHALL NOT (см. требование о терпеливости к долгим метаданным в docs/specs/workflow.md).

Scenario: Метаданные пришли после magnet_timeout

GIVEN задача в failed с error_code magnet_timeout, а её торрент в qBittorrent уже получил метаданные и качается (downloading)
WHEN срабатывает фоновая сверка
THEN задача возвращается в downloading
AND повторный приём того же infohash снова дедуплицируется на неё

Scenario: Торрент уже завершился, пока задача была в failed

GIVEN задача в failed с error_code magnet_timeout, а её торрент в qBittorrent уже готов к раскладке (uploading/stalledUP)
WHEN срабатывает фоновая сверка
THEN задача переходит в completed и продолжает обычный поток (распознавание/раскладка)

Scenario: Источник так и не ожил — состояние не меняется

GIVEN задача в failed с error_code magnet_timeout, а её торрент всё ещё висит в metaDL без метаданных (или отсутствует в qBittorrent)
WHEN срабатывает фоновая сверка
THEN задача остаётся в failed

Scenario: infohash уже занят другой активной задачей

GIVEN задача #1 в failed/magnet_timeout, а тем же infohash уже владеет другая активная задача #2 (приём повторили, пока #1 лежала упавшей)
WHEN источник ожил (торрент получил метаданные или готов) и сверка пытается воскресить #1
THEN #1 остаётся в failed (восстановление не выполняется)
AND активной по этому infohash остаётся #2

8.4 KiB Raw Permalink Blame History Unescape Escape