Идентичность на 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>
This commit is contained in:
Claude Fable 5
@@ -0,0 +1,156 @@
|
||||
# identity — идентичность сущностей домена
|
||||
|
||||
Как система идентифицирует сущности: ULID-ключи и их канонический вид,
|
||||
множество инфохэшей загрузки, дедупликация приёма, корреляция в логах.
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: ULID как первичный ключ сущностей
|
||||
|
||||
Каждая сущность домена SHALL иметь первичный ключ ULID — TEXT, 26 символов
|
||||
Crockford base32, генерируемый приложением в момент создания записи через
|
||||
единственную точку генерации (`internal/ident`). Сущности: `download`,
|
||||
`recognition`, `hint`, `override`, `metadata_candidate`, `file_link`.
|
||||
Канонический вид SHALL быть lowercase. Числовые AUTOINCREMENT-ключи в новых таблицах
|
||||
использоваться SHALL NOT. Идентификатор партии раскладки (`apply_batch_id`)
|
||||
SHALL генерироваться тем же способом.
|
||||
|
||||
#### Scenario: Создание загрузки
|
||||
|
||||
- **WHEN** принимается новая загрузка
|
||||
- **THEN** её `id` — валидный ULID в lowercase
|
||||
- **AND** `id` уникален глобально (не совпадает с id других сущностей)
|
||||
|
||||
#### Scenario: Хронологическая сортировка
|
||||
|
||||
- **GIVEN** две загрузки, созданные последовательно
|
||||
- **WHEN** записи сортируются по `id` лексикографически
|
||||
- **THEN** порядок совпадает с порядком создания
|
||||
|
||||
### Requirement: Нормализация и валидация id на входных границах
|
||||
|
||||
Внешние идентификаторы SHALL валидироваться как ULID и нормализоваться к
|
||||
lowercase до обращения к хранилищу — это касается всех входных границ:
|
||||
URL `/download/{id}`, параметры форм и команд. Синтаксически невалидный id SHALL обрабатываться как
|
||||
несуществующая сущность (404 для страниц), без обращения к БД.
|
||||
|
||||
#### Scenario: Uppercase-вариант id в URL
|
||||
|
||||
- **GIVEN** существующая загрузка с id `01jz…` (lowercase)
|
||||
- **WHEN** клиент открывает `/download/01JZ…` (uppercase)
|
||||
- **THEN** открывается страница той же загрузки
|
||||
|
||||
#### Scenario: Мусор вместо id
|
||||
|
||||
- **WHEN** клиент открывает `/download/abc!!!`
|
||||
- **THEN** ответ — 404, запрос к БД не выполняется
|
||||
|
||||
### Requirement: Множество инфохэшей загрузки
|
||||
|
||||
Загрузка SHALL иметь одну или более записей инфохэша (`download_infohash`:
|
||||
`infohash` lowercase hex, `kind` ∈ `v1`|`v2`). При приёме magnet-ссылки
|
||||
SHALL записываться ВСЕ известные из неё хеши — гибридный magnet несёт и
|
||||
btih (v1), и btmh (v2); `kind` определяется по длине hex (40 — `v1`, 64 —
|
||||
`v2`). Когда qBittorrent сообщает для раздачи оба хеша (`infohash_v1`,
|
||||
`infohash_v2`), система SHALL дописывать недостающие записи загрузке;
|
||||
усечённый хеш v2-only раздачи (поле `hash` qBittorrent, 40 hex от v2)
|
||||
записываться SHALL NOT. Сопоставление раздачи qBittorrent с загрузкой
|
||||
(поллинг, discover) SHALL выполняться по любому из известных хешей. Один и
|
||||
тот же infohash MAY принадлежать нескольким загрузкам во времени (повторный
|
||||
приём после терминального состояния), но активной из них MUST быть не более
|
||||
одной.
|
||||
|
||||
#### Scenario: Гибридный торрент раскрывает оба хеша
|
||||
|
||||
- **GIVEN** загрузка принята по magnet с v1-хешем
|
||||
- **WHEN** qBittorrent отдаёт раздачу с заполненными `infohash_v1` и
|
||||
`infohash_v2`
|
||||
- **THEN** у загрузки появляются обе записи (`kind` = `v1` и `v2`)
|
||||
|
||||
#### Scenario: Сопоставление по v2-хешу
|
||||
|
||||
- **GIVEN** загрузка с записями v1- и v2-хешей
|
||||
- **WHEN** поллинг находит раздачу, совпавшую только по v2-хешу
|
||||
- **THEN** раздача сопоставляется с этой загрузкой
|
||||
|
||||
### Requirement: Дедупликация приёма по любому из хешей
|
||||
|
||||
При приёме система SHALL искать **активную** (нетерминальную) загрузку по
|
||||
любому из известных хешей и, найдя, SHALL возвращать её вместо создания
|
||||
новой. Проверка активности и вставка новой загрузки с её хешами SHALL
|
||||
выполняться атомарно (в одной write-транзакции), поддерживая инвариант «не
|
||||
более одной активной загрузки на infohash». Отдельного снимаемого/
|
||||
восстанавливаемого ключа идемпотентности в схеме быть SHALL NOT — активность
|
||||
выводится только из `state`.
|
||||
|
||||
#### Scenario: Повторный приём при активной загрузке
|
||||
|
||||
- **GIVEN** активная загрузка с infohash `h`
|
||||
- **WHEN** принимается magnet с тем же `h`
|
||||
- **THEN** новая загрузка не создаётся, возвращается существующая
|
||||
|
||||
#### Scenario: Повторный приём после завершения
|
||||
|
||||
- **GIVEN** загрузка с infohash `h` в терминальном состоянии (`done`)
|
||||
- **WHEN** принимается magnet с тем же `h`
|
||||
- **THEN** создаётся новая загрузка со своим ULID и записью `h`
|
||||
|
||||
### Requirement: Атомарность возврата загрузки в активное состояние
|
||||
|
||||
Система SHALL атомарно (в одной write-транзакции) проверять на каждом пути,
|
||||
возвращающем загрузку из терминального состояния в активное (ручной retry,
|
||||
воскрешение фоновой сверкой, повторная раскладка/relink) или создающем её
|
||||
(приём, adopt чужой раздачи), что никакая другая активная загрузка не
|
||||
владеет любым из хешей этой, и при владении SHALL отказывать в переходе,
|
||||
сохраняя инвариант «не более одной активной загрузки на infohash».
|
||||
Отказ SHALL происходить до побочных эффектов во внешних системах
|
||||
(повторного добавления торрента в qBittorrent).
|
||||
|
||||
Та же проверка SHALL применяться к дозаписи хешей загрузке (раскрытие
|
||||
гибридного торрента): хеш, которым владеет другая активная загрузка,
|
||||
дописан быть SHALL NOT. Прямой перевод терминальной загрузки в активное
|
||||
состояние в обход этой проверки SHALL отклоняться хранилищем (механический
|
||||
бэкстоп вместо удалённого unique-индекса).
|
||||
|
||||
#### Scenario: Retry при занятом хеше
|
||||
|
||||
- **GIVEN** загрузка #1 в `failed` с хешем `h`, и другая активная загрузка
|
||||
#2 с тем же `h`
|
||||
- **WHEN** пользователь вызывает retry для #1
|
||||
- **THEN** переход отклоняется с пояснением, #1 остаётся в `failed`
|
||||
- **AND** активной по `h` остаётся #2
|
||||
|
||||
### Requirement: Корреляция сущностей в логах
|
||||
|
||||
Записи журнала, относящиеся к сущности, SHALL содержать её id в атрибуте
|
||||
`<entity>_id` (`download_id`, `recognition_id`, `batch_id`, …); работа в
|
||||
контексте загрузки ведётся через scoped-логгер с `download_id`. Благодаря
|
||||
глобальной уникальности ULID поиск по значению id (grep/jq) SHALL находить
|
||||
все записи журнала, относящиеся к сущности, независимо от имени поля.
|
||||
|
||||
#### Scenario: Путь загрузки по логам
|
||||
|
||||
- **GIVEN** загрузка прошла приём, распознавание и раскладку
|
||||
- **WHEN** журнал фильтруется по значению её `id`
|
||||
- **THEN** находятся записи всех этапов (ingest, recognition, file-layout)
|
||||
|
||||
### Requirement: Миграция существующих записей
|
||||
|
||||
Существующие записи SHALL получить ULID-идентификаторы одной миграцией с
|
||||
сохранением всех связей (FK) и хронологии: timestamp-часть ULID SHALL
|
||||
браться из `created_at` записи, чтобы лексикографический порядок новых id
|
||||
соответствовал историческому порядку создания. Существующий
|
||||
`download.infohash` SHALL быть перенесён в `download_infohash`
|
||||
(нормализация к lowercase, `kind` по длине hex: 40 — `v1`, 64 — `v2`);
|
||||
столбцы `download.infohash` и `download.idempotency_key` SHALL быть удалены.
|
||||
|
||||
#### Scenario: Связи и порядок после миграции
|
||||
|
||||
- **GIVEN** БД с загрузками, распознаваниями и файловыми ссылками на
|
||||
числовых id
|
||||
- **WHEN** миграция выполнена
|
||||
- **THEN** все FK-связи сохранены (распознавания/ссылки указывают на те же
|
||||
загрузки)
|
||||
- **AND** порядок загрузок по `id` совпадает с порядком по `created_at`
|
||||
- **AND** каждый прежний `infohash` представлен записью в
|
||||
`download_infohash`
|
||||
@@ -0,0 +1,113 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user