sprint: набран спринт 2026-08-06 под цель распознавания
- в наборе шесть задач: локаль TVDB и confidence-гейт под цель, плюс баги и техдолг помимо неё - взятым дописаны разделы своего типа: «Затрагивает», критерии с оракулами, воспроизведение - решены развилки: оба расхождения код↔спека правятся спекой (и потому стали chore), опрос qBittorrent тормозится бэкоффом до минутного потолка
This commit is contained in:
@@ -49,6 +49,31 @@
|
||||
которому порог можно было бы подобрать заранее, решено не собирать
|
||||
(`../REJECTED.md`, 2026-08-06), так что первое значение остаётся оценкой.
|
||||
|
||||
## Затрагивает
|
||||
|
||||
- `internal/recognize` — `decide`/`validate.go` (четвёртое условие) и
|
||||
`recognize.go` (пере-применение дефолта, из-за которого `0` не выключает
|
||||
гейт);
|
||||
- секция `[recognition]` конфига, `config.example.toml` и значение по умолчанию
|
||||
в `internal/config`;
|
||||
- `openspec/specs/recognition/spec.md` — требование «Модель уверенности и
|
||||
решение auto/review»;
|
||||
- `docs/database.md` (дом числа) и `docs/conventions/config.md` (описание ключа).
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- `auto_confidence_threshold = 0` выключает гейт: при чистых условиях 1–3
|
||||
раздача уходит в авто независимо от `confidence` (оракул: тест `decide` с
|
||||
нулевым порогом).
|
||||
- При `confidence` ниже порога и выполненных условиях 1–3 раздача уходит в
|
||||
review (оракул: табличный тест на границе порога — ниже, равно, выше).
|
||||
- Умолчание равно 0.7 в одном месте — загрузке конфига; `recognize.go` своего
|
||||
дефолта не применяет (оракул: тест, что пустой конфиг даёт 0.7, плюс
|
||||
отсутствие `defaultAutoThreshold` в диффе).
|
||||
- Спека называет `confidence` четвёртым конфигурируемым блокирующим условием и
|
||||
несёт сценарий «матч чист, но уверенность ниже порога → review» (оракул:
|
||||
`openspec validate --strict`).
|
||||
|
||||
Оформить как OpenSpec-change (дельта `recognition` + правки
|
||||
`validate.go`/`recognize.go`/`config`).
|
||||
|
||||
|
||||
@@ -1,14 +1,13 @@
|
||||
# 🐞 Не штормить ERROR при недоступном qBittorrent и эскалировать устойчивый сбой тика
|
||||
# 🐞 Тормозить опрос qBittorrent бэкоффом при недоступности и эскалировать устойчивый сбой
|
||||
|
||||
- **Тип:** fix
|
||||
- **Категория:** Инфраструктура
|
||||
- **Зачем:** Остаток задачи логирования: ext.* ERROR-шторм при недоступном qBittorrent + эскалация устойчивого сбоя тика _(ревью Fable)_
|
||||
- **Теги:** goal:operational-resilience
|
||||
- **Зачем:** недоступный qBittorrent опрашивается каждые 5 с и даёт WARN на каждом тике: нужен экспоненциальный бэкофф до минутного потолка со сбросом по первому успеху и ERROR на устойчивой деградации
|
||||
|
||||
Остаток от задачи «классификация доменных ошибок + конвенции логирования»
|
||||
(основное реализовано, см. ниже). Здесь — два смежных пункта про уровень
|
||||
повторяющихся сбоев фоновых циклов, каждый требует небольшого решения, а не
|
||||
только правки.
|
||||
(основное реализовано, см. ниже) плюс бэкофф опроса, заказанный 2026-08-06.
|
||||
Речь о поведении фонового цикла, пока зависимость лежит: с какой частотой он её
|
||||
дёргает и каким уровнем об этом пишет.
|
||||
|
||||
## Что уже сделано (не переоткрывать)
|
||||
|
||||
@@ -29,29 +28,63 @@
|
||||
|
||||
## Остаток
|
||||
|
||||
### ERROR-шторм при недоступном qBittorrent
|
||||
**Шум `ext.*` ERROR решено оставить как есть (2026-08-06).** Запись
|
||||
«зависимость недоступна» на каждом тике — легитимный сигнал транспортного слоя,
|
||||
и гасится он уровнем сбора логов, а не кодом. Варианты с пониженным уровнем у
|
||||
`logging.ExtCall` и с дедупом отклонены: первый заводит второе правило уровня
|
||||
для того же класса вызовов, второй даёт транспортному логгеру память о
|
||||
состоянии.
|
||||
|
||||
Клиент `qbt` логирует `ext.*` `Failure` → **ERROR** на каждом тике поллинга
|
||||
(`torrents/info`, `internal/qbt/qbt.go`), пока qBittorrent недоступен (рестарт
|
||||
демона, сеть). Домен уже пишет `poll failed` = WARN (по новой конвенции), но
|
||||
транспортная `ext.*`-запись остаётся ERROR по правилу ext-конвенции («сервис
|
||||
недоступен → ERROR»). При частом поллинге это шумит.
|
||||
Остаются две вещи, и обе стоят на одном счётчике подряд-идущих сбоев тика.
|
||||
|
||||
Развилка (решить до правки):
|
||||
**Бэкофф опроса (решение 2026-08-06).** Пока qBittorrent недоступен, цикл
|
||||
продолжает дёргать его каждые `poll_interval` (5 с) — недоступную зависимость
|
||||
незачем опрашивать с рабочей частотой. Интервал растёт экспоненциально от
|
||||
`poll_interval` до потолка порядка минуты; первый успешный ответ возвращает
|
||||
рабочий интервал сразу, без ступенчатого спуска. Бэкофф заодно снимает и остроту
|
||||
шума: записей становится столько же на событие, но событий — единицы в минуту.
|
||||
|
||||
- (а) Ввести у `logging.ExtCall` вариант с пониженным уровнем для рутинно-частых
|
||||
вызовов (симметрично `SuccessDebug`) — поллинг-вызовы (`torrents/info`) на
|
||||
транзиентном сбое пишут WARN, не ERROR;
|
||||
- (б) Дедуп/circuit-breaker: первый ERROR, дальше тишина до восстановления;
|
||||
- (в) Оставить как есть, признав `ext.*` ERROR легитимным сигналом «зависимость
|
||||
лежит» (тогда шум гасить уровнем сбора, а не кодом).
|
||||
**Эскалация уровня.** Сейчас сбой тика — **всегда WARN**, сколько бы тиков
|
||||
подряд он ни падал. `docs/conventions/logging.md` требует иного: устойчивый сбой
|
||||
N тиков подряд — это реальная деградация, и она пишется ERROR.
|
||||
|
||||
### Эскалация устойчивого сбоя тика
|
||||
## Воспроизведение
|
||||
|
||||
Сейчас транзиентный сбой тика = WARN всегда. Договорённость на будущее
|
||||
(`logging.md`): устойчивый сбой N тиков подряд эскалировать в ERROR (реальная
|
||||
деградация, а не разовый промах). Не реализовано — нужен счётчик подряд-сбоев по
|
||||
циклу и порог в конфиге.
|
||||
1. Остановить qBittorrent (локально, не на umbar).
|
||||
2. Смотреть лог воркера в течение нескольких минут поллинга.
|
||||
3. Наблюдается: запрос к qBittorrent уходит каждые 5 секунд всё время
|
||||
недоступности, а доменная запись `poll failed` идёт WARN на каждом тике и
|
||||
остаётся WARN бесконечно.
|
||||
4. Ожидается: интервал опроса растёт до минутного потолка, а после N
|
||||
подряд-идущих неудачных тиков уровень поднимается до ERROR — деградация
|
||||
отличается от разового промаха.
|
||||
5. Поднять qBittorrent обратно: опрос возвращается к `poll_interval` с первого
|
||||
успешного ответа.
|
||||
|
||||
Вердикт: мелкая надёжностная полировка, не блокер. Делать вместе (обе про
|
||||
уровень сбоев фоновых циклов) или отдельной строкой.
|
||||
## Затрагивает
|
||||
|
||||
- цикл поллинга воркера (`internal/worker`) — счётчик подряд-идущих сбоев,
|
||||
текущий интервал тика и его сброс по успеху;
|
||||
- секция `[worker]` конфига и `config.example.toml` — потолок бэкоффа и порог
|
||||
эскалации;
|
||||
- `docs/database.md`, таблица «Настройки с числовым значением» — дом обоих
|
||||
чисел;
|
||||
- `docs/architecture.md`, «Характер потока» — там сказано, что фон непрерывный с
|
||||
периодом поллинга; переменный интервал это уточняет;
|
||||
- `docs/conventions/logging.md` — правило эскалации уже записано, меняться не
|
||||
должно; задача приводит код к нему.
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- При подряд-идущих сбоях интервал опроса растёт экспоненциально от
|
||||
`poll_interval` и упирается в потолок из конфига, дальше не растёт (оракул:
|
||||
тест цикла с подставным клиентом и управляемыми часами — проверяет
|
||||
последовательность интервалов).
|
||||
- Первый успешный ответ возвращает `poll_interval` немедленно (оракул: тот же
|
||||
тест, сценарий «серия сбоев, успех, сбой» — после успеха интервал рабочий).
|
||||
- Сбой тика ниже порога пишется WARN, начиная с N-го подряд — ERROR, а успешный
|
||||
тик сбрасывает счётчик (оракул: тест, считающий уровни записей на сценарии
|
||||
«сбой, сбой, успех, сбой»).
|
||||
- Потолок бэкоффа и порог эскалации читаются из конфига и описаны в
|
||||
`config.example.toml` с единицами и диапазоном (оракул: `task gate`, шаг
|
||||
канона — сверка с `database.md`).
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
# 🐞 Пересобирать `addReq` из свежего `source_type` перед `Add` (окно namer'а)
|
||||
# 🧹 Уточнить в спеке требование о re-read `source_type` перед `Add`
|
||||
|
||||
- **Тип:** fix
|
||||
- **Тип:** chore
|
||||
- **Категория:** Ядро продукта
|
||||
- **Зачем:** При апгрейде magnet→.torrent в окне namer'а добавится magnet из устаревшего снимка; самоисцеляется через magnet_timeout→failed→Retry _(аудит 2026-07-17)_
|
||||
- **Теги:** goal:state-integrity
|
||||
- **Зачем:** спека требует перечитывать source_type непосредственно перед добавлением, код перечитывает после тик-снимка — узкое namer-окно самоисцеляется через Retry и признано допустимым
|
||||
|
||||
Найдено аудитом capability **download-tracking** (сверка код↔спека после пачки
|
||||
lifecycle-задач). Пред-существующее, вне scope задачи F3/cancel-cleanup — T4
|
||||
@@ -35,22 +34,42 @@ lifecycle-задач). Пред-существующее, вне scope зада
|
||||
«источник неприкосновенен» не задет. Окно узкое (апгрейд должен лечь ровно в
|
||||
LLM-вызов по тому же infohash). Поэтому средний, не высокий.
|
||||
|
||||
## Развилка (решить до кода)
|
||||
## Решение (2026-08-06): B — привести спеку к коду
|
||||
|
||||
- **A — ужесточить код (соответствие букве спеки, закрыть окно):** после re-read
|
||||
`before` под замком (`:484`) пересобирать `addReq`/`hint` из `before`, если
|
||||
`source_type` изменился. Нюанс: `sourceAddParts` читает байты `.torrent` — это
|
||||
тяжёлый вызов, держать под замком нельзя (спека: тяжёлое — вне блокировки), плюс
|
||||
подсказка имени для `.torrent` иная (метаданные раздачи vs имя из magnet), т.е.
|
||||
при апгрейде корректно был бы и повторный namer. Не однострочник.
|
||||
- **B — смягчить спеку (принять реальность):** признать, что рациональ («не
|
||||
полагаться на снимок, снятый ранее вне блокировки») уже выполнен первым re-read
|
||||
под замком на `:447`, и переформулировать требование как «перечитывать
|
||||
`source_type` под блокировкой после тик-снимка», явно приняв узкое namer-окно
|
||||
как самоисцеляемое через `Retry`.
|
||||
Рациональ требования — «не полагаться на снимок, снятый ранее вне блокировки» —
|
||||
уже выполнен первым re-read под замком на `:447`. Требование переформулируется
|
||||
как «перечитывать `source_type` под блокировкой после тик-снимка», а узкое
|
||||
namer-окно принимается явно: оно самоисцеляется через `magnet_timeout` →
|
||||
`failed` → `Retry`.
|
||||
|
||||
Рекомендация — начать с B (дёшево, отражает фактическое осознанное поведение), A
|
||||
завести только если узкое окно окажется реальной болью в эксплуатации.
|
||||
Вариант A (пересобирать `addReq` из `before` под замком) отклонён: не
|
||||
однострочник — `sourceAddParts` читает байты `.torrent`, держать это под
|
||||
блокировкой нельзя, а при апгрейде корректно был бы и повторный вызов namer'а.
|
||||
Заводить его отдельной задачей, только если узкое окно окажется реальной болью в
|
||||
эксплуатации.
|
||||
|
||||
Кода задача не трогает: наблюдаемое поведение остаётся прежним, меняется
|
||||
заявленное.
|
||||
|
||||
## Затрагивает
|
||||
|
||||
- `openspec/specs/download-tracking/spec.md` — требование про re-read
|
||||
`source_type` перед добавлением, его формулировка и сценарии;
|
||||
- дельта-спека change'а — новых сценариев с namer-окном может потребоваться два
|
||||
(апгрейд до тик-снимка и апгрейд в окне namer'а);
|
||||
- `internal/worker/worker.go` — только чтение, правок не предполагается.
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- Требование спеки описывает фактическое поведение: re-read `source_type` под
|
||||
блокировкой после тик-снимка, апгрейд в окне namer'а назван допустимым и
|
||||
самоисцеляемым (оракул: `openspec validate --strict`).
|
||||
- В спеке есть сценарий, покрывающий апгрейд в окне namer'а с исходом «magnet из
|
||||
снимка, дальше `magnet_timeout` → `failed` → `Retry`» (оракул: тот же прогон
|
||||
плюс существующий `TestProcessCatchedReReadsSourceTypeUnderLock` продолжает
|
||||
проходить без правок).
|
||||
- Ни один файл под `internal/` в диффе не изменён (оракул: `git diff --stat`
|
||||
в отчёте ревью).
|
||||
|
||||
## Ссылки
|
||||
|
||||
|
||||
@@ -1,9 +1,8 @@
|
||||
# 🐞 Не терять маркер `user_dismiss` при закрытии не-терминальной загрузки из веб-UI
|
||||
# 🧹 Зафиксировать в спеке разделение Cancel и Dismiss по состояниям
|
||||
|
||||
- **Тип:** fix
|
||||
- **Тип:** chore
|
||||
- **Категория:** Ядро продукта
|
||||
- **Зачем:** Функционально ок (Cancel даёт cancelled), но маркер user_dismiss в error_code теряется; расхождение с буквой спеки _(аудит 2026-07-17)_
|
||||
- **Теги:** goal:state-integrity
|
||||
- **Зачем:** спека обещает dismiss из любого состояния, код осознанно даёт Cancel для активных и Dismiss для терминальных — расходится буква, а не поведение
|
||||
|
||||
Найдено аудитом capability **state-reconciliation** (сверка код↔спека).
|
||||
Пред-существующее, вне scope пачки lifecycle-задач.
|
||||
@@ -31,16 +30,36 @@
|
||||
наблюдаемости (в аналитике/логах не отличить «пользователь закрыл активную» от
|
||||
«пользователь отменил»). Отсюда низкий приоритет.
|
||||
|
||||
## Развилка (решить до кода)
|
||||
## Решение (2026-08-06): B — привести спеку к коду
|
||||
|
||||
- **A — привести код к спеке:** веб-UI на не-терминальных тоже зовёт `Dismiss`
|
||||
ради единого маркера `user_dismiss`; либо `Cancel` пишет `user_dismiss`.
|
||||
- **B — привести спеку к коду:** зафиксировать осознанное разделение (`Cancel`
|
||||
для активных, `Dismiss` для терминальных) — уточнить требование, что стоп-кран
|
||||
на не-терминальных реализуется `Cancel`'ом, и определить, какой `error_code`
|
||||
ожидается.
|
||||
Разделение осознанное: `Cancel` — стоп-кран для активных состояний, `Dismiss` —
|
||||
закрытие терминальных. Требование «Ручное закрытие» уточняется: на
|
||||
не-терминальных состояниях закрытие из интерфейса реализуется `Cancel`'ом, и
|
||||
называется, какой `error_code` при этом ожидается.
|
||||
|
||||
Сначала решить, осознанно ли разделение Cancel/Dismiss; если да — вероятно B.
|
||||
Вариант A (звать `Dismiss` из веб-UI на не-терминальных ради единого маркера)
|
||||
отклонён: он меняет рабочее поведение ради маркера в диагностике.
|
||||
|
||||
Кода задача не трогает: наблюдаемое поведение остаётся прежним, меняется
|
||||
заявленное.
|
||||
|
||||
## Затрагивает
|
||||
|
||||
- `openspec/specs/state-reconciliation/spec.md` — требование «Ручное закрытие»:
|
||||
доступность `dismiss` по состояниям и ожидаемый `error_code`;
|
||||
- дельта-спека change'а — сценарий закрытия не-терминальной загрузки из веб-UI;
|
||||
- `internal/httpapi/download.go`, `web/templates/partials/download_main.html` —
|
||||
только чтение, правок не предполагается.
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- Требование спеки различает `Cancel` и `Dismiss` по состояниям и называет
|
||||
`error_code` для каждого пути закрытия (оракул: `openspec validate --strict`).
|
||||
- В спеке есть сценарий «пользователь закрывает не-терминальную загрузку из
|
||||
веб-UI» с исходом `cancelled` и названным `error_code` (оракул: тот же
|
||||
прогон).
|
||||
- Гейт `Dismissable` в коде и danger-zone шаблона остаются как есть (оракул:
|
||||
`git diff --stat` в отчёте ревью — файлов под `internal/` и `web/` нет).
|
||||
|
||||
## Ссылки
|
||||
|
||||
|
||||
@@ -3,7 +3,6 @@
|
||||
- **Тип:** chore
|
||||
- **Категория:** Ядро продукта
|
||||
- **Зачем:** косметика приёма: NoName в контексте, устаревшие комментарии, лог, bencode-аллокации _(ревью 2026-07-08)_
|
||||
- **Теги:** goal:state-integrity
|
||||
|
||||
Ревью Fable 2026-07-08 (приём). Косметические нити.
|
||||
|
||||
@@ -16,3 +15,26 @@ N4 — qbt.go:246 логирует «Fails.» со счётчиками, но qB
|
||||
N5 — anacrolix bencode (v1.61.0, bencode/decode.go:17,250) аллоцирует до MaxStrLen (~128MiB) на объявленную строку до чтения — крафт-8MiB-торрент может форсить транзиентные ~128MiB аллокации при metainfo.Load. Ограничено и завершается ошибкой; на umbar приемлемо, но знать стоит. (files()-panic-guard torrent.go НЕ покрывает Load/UnmarshalInfo/HashBytes, но panic-путей там не найдено.)
|
||||
|
||||
Вердикт: простые фиксы/принять.
|
||||
|
||||
## Затрагивает
|
||||
|
||||
- `internal/torrent/torrent.go` — `Context()` и фильтр NoName-сентинела «-»;
|
||||
- `internal/httpapi/httpapi.go` и `internal/tgbot/bot.go` — устаревшие
|
||||
комментарии про непустой `DownloadID` на пути ошибки;
|
||||
- `internal/qbt/qbt.go` — лог `Fails.` без причины;
|
||||
- N5 (аллокации bencode в `anacrolix/torrent`) — граница чужой библиотеки,
|
||||
правке не подлежит: исход пункта — запись наблюдения, а не код.
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- Для безымянного торрента `Context()` не отдаёт «-» как название — поле пустое
|
||||
(оракул: тест разбора на фикстуре безымянного торрента в
|
||||
`internal/torrent`).
|
||||
- Комментарии в `httpapi` и `tgbot` описывают фактическое поведение `Ingest`:
|
||||
на любом пути ошибки возвращается пустой `Result`, корреляция идёт по
|
||||
`request_id` (оракул: чтение диффа на ревью — механического оракула нет).
|
||||
- Лог неудачного добавления в qBittorrent несёт инфохэш для корреляции (оракул:
|
||||
тест клиента с подставным сервером, проверяющий поля записи).
|
||||
- Наблюдение про аллокации bencode до `MaxStrLen` записано в
|
||||
`docs/research/` с провенансом либо явно отклонено строкой в теле задачи
|
||||
(оракул: `task gate`, шаг канона).
|
||||
|
||||
@@ -32,6 +32,16 @@
|
||||
([metadata-match](../../../openspec/specs/metadata-match/spec.md)) написано
|
||||
только под TMDB — либо обобщается на провайдеров, либо получает соседа.
|
||||
|
||||
## Затрагивает
|
||||
|
||||
- `internal/metadata/tvdb.go` — `TVDBConfig` (поле языка), строка запроса
|
||||
`Search`, разбор переводов и `OriginalTitle` в кандидате;
|
||||
- `cmd/jellybit/serve.go` — сборка провайдера TVDB из конфига;
|
||||
- `openspec/specs/metadata-match/spec.md` — требование «Локаль запроса к TMDB»:
|
||||
обобщается на провайдеров либо получает соседа под TVDB;
|
||||
- внешний контракт: поиск TVDB (`/search`) и его блок переводов — формат
|
||||
сверяется живым прогоном под `TVDB_API_KEY`, наугад не пишется.
|
||||
|
||||
## Критерии приёмки
|
||||
|
||||
- Запрос поиска TVDB содержит параметр языка, выведенный из `[general].language`
|
||||
|
||||
Reference in New Issue
Block a user