From f3dacaaa3911dc1f0d0a270a68e733158cd7a5bc Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Mon, 28 Sep 2026 15:24:26 +0600 Subject: [PATCH] [2026-09-28] eagle: family/plans/lidarr-taiga-deploy.md personal/projects/balda/balda.md personal/tech/adk-hostedagent-openai-mcp.md personal/tech/flaresolverr-taiga.md --- family/plans/lidarr-taiga-deploy.md | 25 +++-- personal/projects/balda/balda.md | 2 +- personal/tech/adk-hostedagent-openai-mcp.md | 64 ++++++++++- personal/tech/flaresolverr-taiga.md | 116 ++++++++++++++++++-- 4 files changed, 185 insertions(+), 22 deletions(-) diff --git a/family/plans/lidarr-taiga-deploy.md b/family/plans/lidarr-taiga-deploy.md index eca5f41a..5303eac4 100755 --- a/family/plans/lidarr-taiga-deploy.md +++ b/family/plans/lidarr-taiga-deploy.md @@ -3,14 +3,25 @@ **Дата:** 2026-09-28 **Статус:** ✅ **РАБОЧИЙ — приёмка закрыта 2026-09-28 (вечер).** SkyHook-блокер снят, проверено end-to-end: lookup → добавление артиста → поиск релизов. Бал: 0 артистов → 1, -0 релизов → 23. +0 релизов → 43. **Добивка (2026-09-28, поздний вечер):** Radarr и Sonarr вычищены до `health: []` (`docker restart` + снятие карантина в Prowlarr + `?forceSave=true`). Найден и исправлен последний дефект Lidarr — **`proxyBypassFilter` без внутренних docker-имён** (см. питфолл). -✅ **Все правки применены, включая `docker restart lidarr`** — задача задач закрыта; -из приёмки остаются только 2 дефекта на стороне САМИХ трекеров (не инфраструктура): -RuTracker требует капчу на логин (нужен ручной вход Alex), RuTor не отдаёт категории -фильмов/сериалов. Оба разобраны в [[personal/tech/flaresolverr-taiga]]. +✅ **Все правки применены, включая `docker restart lidarr`** — задача закрыта. +**Финал сессии:** RuTracker **починен Alex'ом** (логин жив; капча отдаётся только «холодным» +сессиям — `session=prowlarr` её обходит, см. [[personal/tech/flaresolverr-taiga]]), +карантин снят тестом полным объектом → Prowlarr `indexerstatus` → `[]`, `caps` → **200**. +**Найден и закрыт дефект пути загрузки:** `musicCategory` была **пустая** → Transmission +положил бы файл без категории, и **импорт в библиотеку упал бы**. Исправлено на +`musicCategory=lidarr` (дефолт Lidarr, НЕ `music`; каталог `/mnt/storage/Downloads/lidarr` +уже существует). Проверено: root folder `/storage/Music` (978 ГБ free), RemotePathMapping +`/mnt/storage/Downloads/ → /storage/Downloads/`, скачается в `/storage/Music//`, +поиск релизов → **43** FLAC-раздачи. +⚠️ **Открыт 1 дефект, на стороне САМОГО трекера (не инфраструктура):** RuTor — +`no results in the configured categories` (не отдаёт фильмы/сериалы). Не блокировка, не карантин. +⚠️ **Остаток-механика:** `docker restart radarr sonarr lidarr` — сбросить **кэш health** +со старым RuTracker (команда ждала апрува Alex, в сессии не выполнена). +Разобрано в [[personal/tech/flaresolverr-taiga]]. **Что было причиной и как починено (главный вывод сессии):** `api.lidarr.audio` действительно за Cloudflare, прямой запрос с IP Тайги → **403**, через `socks5h://vless-proxy:1080` → **200**. НО **env-переменные `HTTP_PROXY`/`HTTPS_PROXY` Lidarr @@ -35,8 +46,8 @@ RuTracker требует капчу на логин (нужен ручной в |---|---| | Контейнер | `lidarr` **v3.1.0.4875-ls42**, Up, сети `caddy_default` + `media_net` | | API-ключ | `166654ac3f054096ae0e8393fb1bf940` | -| Root folder | `/storage/Music`, `accessible: true`, 913 ГБ свободно (id=1) | -| Download client | Transmission (id=1), тест связи → **200**; `musicCategory=""` | +| Root folder | `/storage/Music`, `accessible: true`, 978 ГБ свободно (id=1) | +| Download client | Transmission (id=1), тест связи → **200**; `musicCategory="lidarr"` ✅ (была пустая — исправлено) | | Naming | `renameTracks=true`, `{Artist Name}/{Album Title}/{track:00} - {Track Title}` | | Prowlarr Application | `Lidarr` **id=3**, `fullSync`, `syncCategories=[3000,3010,3020,3030,3040,3050,3060]` | | Индексер в Lidarr | `NoNaMe Club (Prowlarr)` (id=2) — `rss=true`, `auto=true` | diff --git a/personal/projects/balda/balda.md b/personal/projects/balda/balda.md index 89c5327a..93894346 100755 --- a/personal/projects/balda/balda.md +++ b/personal/projects/balda/balda.md @@ -14,7 +14,7 @@ | Репо | Что там | PR | |---|---|---| | **`baldaworks/balda`** | сам бот, транспорты (Mattermost, Zulip) | [#8](https://github.com/baldaworks/balda/pull/8) Mattermost, OPEN · [#1](https://github.com/baldaworks/balda/pull/1) Zulip, merged | -| **`normahq/runtime`** | библиотека рантайма (`agentfactory`, `hostedagent`) | [#5](https://github.com/normahq/runtime/pull/5) фикс MCP-тулинга, OPEN · [#4](https://github.com/normahq/runtime/pull/4) OpenAI tool_calls, OPEN | +| **`normahq/runtime`** | библиотека рантайма (`agentfactory`, `hostedagent`) | [#5](https://github.com/normahq/runtime/pull/5) фикс MCP-тулинга, OPEN · **`CHANGES_REQUESTED`** (3 дефекта, план — [[personal/plans/runtime-pr5-toolset-dedup-review-fixes]]) · [#4](https://github.com/normahq/runtime/pull/4) OpenAI tool_calls, OPEN (4 дефекта закрыты, [[personal/plans/runtime-pr4-openai-toolcalls-fixes]]) | Форки: `mallexxx/balda`, `mallexxx/runtime` — **разные**, клоны тоже разные. Детали по runtime-PR → [[personal/projects/balda/balda-valera]]. diff --git a/personal/tech/adk-hostedagent-openai-mcp.md b/personal/tech/adk-hostedagent-openai-mcp.md index 62c55562..2e0c4e6d 100755 --- a/personal/tech/adk-hostedagent-openai-mcp.md +++ b/personal/tech/adk-hostedagent-openai-mcp.md @@ -3,6 +3,9 @@ > Создано 2026-09-27. Зеркало скилла [[software-development/adk-hostedagent-openai-mcp|`adk-hostedagent-openai-mcp`]]. > Здесь — **исправление к скиллу** и разбор дефекта, найденного на Балде. > Проект: [[personal/plans/balda-mm-phase4-agents]] §19, [[personal/projects/balda/balda-kraken-mm-deploy]] §19. +> +> 🔴 **ОБНОВЛЕНО 2026-09-28:** первая версия фикса дедупа (§4) и два теста (§5, §6) +> **отклонены ревью PR #5**. Правки помечены в §4a / §5 / §6 — читать их вместе с §4. --- @@ -94,7 +97,12 @@ extraMCPServerIDs = append(extraMCPServerIDs, binding.ID) --- -## 4. Фикс — дедуп по эндпоинту +## 4. Фикс — дедуп по эндпоинту ⚠️ (ОТВЕРГНУТ ревью PR #5, 2026-09-28) + +> 🔴 **Статус: первая версия фикса отклонена ревьюer'ом metalagman в +> [[personal/plans/runtime-pr5-toolset-dedup-review-fixes|PR #5]] (`CHANGES_REQUESTED`).** +> Ниже — как было сделано; что именно неверно и чем заменяем — см. §4a. Не копировать +> этот раздел в новые реализации. **Файл:** `runtime-local/agentfactory/agentfactory.go`, функция `hostedToolsets`. @@ -119,6 +127,29 @@ extraMCPServerIDs = append(extraMCPServerIDs, binding.ID) --- +## 4a. Почему версия из §4 неверна (ревью PR #5, 2026-09-28) + +Три замечания ревьюer'а, все подтверждены фактами. Разбор и план — [[personal/plans/runtime-pr5-toolset-dedup-review-fixes]]. + +| # | Severity | Что не так | +|---|---|---| +| P1 | **blocking** | `mcpEndpointKey` стирает **все** query-параметры, а `Headers` в ключе не участвуют. Query и headers выбирают тенанта / авторизационный контекст. `/mcp?tenant=a` vs `/mcp?tenant=b`, или один URL с разными `Authorization` → схлопываются в один произвольный конфиг = **доступ к чужому tool-set**. Вывод идентичности из host/path — небезопасен. | +| P2 | test gap | `selectScopedOnly` (§5) **дублирует алгоритм продакшена** и сам вычисляет «ожидаемого» победителя → не проверяет фактически удержанный конфиг. Вакуумный ассерт. | +| P2 | test gap | Пробник `ProcessRequest(ctx any, req any)` (§6) — Go требует **точных** типов, реальная подпись `(agent.Context, *model.LLMRequest)` его **не** удовлетворяет → проверка не может сработать. | + +📌 **Направление замены (ожидает одобрения Alex):** +- generic-слой (`agentfactory`) **перестаёт выводить** идентичность из формы URL; +- схлопывание только по **явному** ключу — предлагается `DedupKey string` в + `agentconfig.MCPServerConfig` (альтернатива — `Aliases []string`); +- Balda объявляет свой дубль **сама** в composition layer — `internal/apps/balda/agent/runtime_manager.go:344` + (`registry.Set(binding.ID, binding.Config)`) — ровно этого просит ревьюer («resolve the Balda-specific + duplicate in the Balda composition layer»); +- победитель — **детерминированный** (lexicographic) или явное поле, но **не** эвристика по наличию query. + +⚠️ Разные `?tenant=`/`Authorization` в общем слое обязаны оставаться **разными серверами**. + +--- + ## 5. Проверка (что реально подтверждает фикс) | Проверка | Команда | Ожидание | @@ -138,6 +169,15 @@ extraMCPServerIDs = append(extraMCPServerIDs, binding.ID) не ломало). Добавлен `selectScopedOnly` — теперь тест падает, если выживает не scoped-запись. Слабый тест = ложная уверенность. +🔴 **НО: `selectScopedOnly` тоже признан вакуумным (ревью PR #5, §4a P2).** Он **копирует цикл +`hostedToolsets`** внутри теста и возвращает «ожидаемого» победителя сам — проверяется копия +алгоритма, а не реально удержанный конфиг (`hostedToolsets` отдаёт непрозрачные `tool.Toolset`; +тест считает только `len()`). Если поменять приоритет синхронно в проде и в копии — тест останется +зелёным. **Правильная форма:** ассертить фактически использованный endpoint — либо через +инъектируемый конструктор транспорта (тестовый хук, подмена в тесте + проверка `Transport.Endpoint`), +либо подняв реальные httptest-MCP-серверы с разными tool-листами. Урок усиливается: **копия логики +в тесте — тот же класс ошибки, что терпимый ассерт.** Тест обязан наблюдать **результат продакшена**. + --- ## 6. Метод: исполняемый пробник вместо чтения @@ -146,13 +186,32 @@ extraMCPServerIDs = append(extraMCPServerIDs, binding.ID) за секунду: ```go +import ( + "google.golang.org/adk/v2/agent" + "google.golang.org/adk/v2/model" +) + type requestProcessor interface { - ProcessRequest(ctx any, req any) error + ProcessRequest(ctx agent.Context, req *model.LLMRequest) error } if _, ok := toolset.(requestProcessor); ok { t.Fatal("unexpected: premise changed") } ``` +🔴 **Типы должны быть ТОЧНЫМИ (ревью PR #5, §4a P2).** Изначальная форма +`ProcessRequest(ctx any, req any) error` — **вакуумная**: Go требует точного совпадения типов, +поэтому реальный метод `(agent.Context, *model.LLMRequest)` такой интерфейс **не** реализует, +`ok` всегда `false`, `t.Fatal` **недостижим**. Пробник выглядел как проверка, но не проверял +ничего — ровно та же болезнь, что «терпимый ассерт» в §8. Полезное дополнение: **позитивный +контроль** — рядом проверить, что интерфейс реализуется заведомо подходящим типом; если сигнатура +разъедется, тест это покажет. + +⚠️ Тип `agent.Context` в `adk/v2` — **интерфейс** (`github.com/google/uuid`-подобных полей нет). +Продакшн-подписи подтверждены в модульном кэше: +`adk/v2@v2.4.0/internal/toolinternal/tool.go:41` и `tool/tool.go:192`: +```go +ProcessRequest(ctx agent.Context, req *model.LLMRequest) error +``` 📌 **Правило:** когда гипотеза касается **интерфейса или пути вызова** — писать исполняемый пробник, а не читать дальше. Чтение даёт правдоподобные версии; тест даёт факт. @@ -233,6 +292,7 @@ runtime. Правки в `~/Developer/runtime-local` **не доезжают** ## Связанные заметки +- [[personal/plans/runtime-pr5-toolset-dedup-review-fixes]] — **PR #5: 3 дефекта ревью дедупа MCP-тулсетов**, план замены (§4a) - [[personal/plans/runtime-pr4-openai-toolcalls-fixes]] — PR #4: 4 дефекта, фиксы, тесты - [[personal/plans/balda-mm-phase4-agents]] — §19 (корень, фикс, тесты, приёмка), §16.2 и §18 опровергнуты - [[personal/projects/balda/balda-kraken-mm-deploy]] — Фаза 3, образ `balda-mm:0.1.13` diff --git a/personal/tech/flaresolverr-taiga.md b/personal/tech/flaresolverr-taiga.md index 371b3362..6b6b4c32 100755 --- a/personal/tech/flaresolverr-taiga.md +++ b/personal/tech/flaresolverr-taiga.md @@ -1,11 +1,12 @@ # FlareSolverr на Тайге + обход блокировок индексеров -> ✅ **СОСТОЯНИЕ 2026-09-28 (финал): инфраструктура готова, 2 дефекта на стороне трекеров.** -> **Prowlarr** — `health` → `[]`, 6/6 индексеров настроены; RuTracker в карантине (капча, см. ниже). -> **Radarr** — `health` → `[]`. **Sonarr** — `health` → `[]`. -> **Lidarr** — SkyHook работает, 1 артист, поиск релизов отдаёт результаты. -> ⚠️ Открыто: **RuTracker — капча на логин** (нужен ручной вход Alex), **RuTor — категории** -> (не отдаёт фильмы/сериалы). Оба — на стороне трекеров, не инфраструктура. +> ✅ **СОСТОЯНИЕ 2026-09-28 (поздний вечер, ФИНАЛ): ГЛАВНЫЙ ДЕФЕКТ ЗАКРЫТ — RuTracker починен Alex'ом.** +> **Prowlarr** — `health` → `[]`, `indexerstatus` → `[]`, `caps` 1/5/6 → **200**, 6/6 настроены, RuTracker **вне карантина**. +> **Radarr/Sonarr/Lidarr** — на момент последнего аудита держали **кэш health** со старым `RuTracker`; +> лечится `docker restart radarr sonarr lidarr` (команда ждала апрува Alex — не выполнена в этой сессии). +> **Lidarr** — SkyHook работает, `musicCategory=lidarr` применён (202), поиск релизов отдаёт **43** FLAC-раздачи. +> ⚠️ Открыто **1**: **RuTor** — `no results in the configured categories` (трекер не отдаёт фильмы/сериалы, +> не блокировка и не карантин). Всё остальное закрыто. > Контейнер `flaresolverr` (v3.5.2), порт `8191`, сеть `media_net`, `shm_size: 1gb`, > `LOG_LEVEL=warning`, **`PROXY_URL=socks5://vless-proxy:1080`**. > Compose — `/mnt/RED_2TB/docker/arr/docker-compose.yml` (6-й сервис). @@ -285,6 +286,50 @@ RuTracker Auth Failed` и `Invalid Credentials for RuTracker [https://rutracker. каскад `429:TooManyRequests` в Radarr/Sonarr/Lidarr. Это нормальное поведение, лечится только восстановлением логина. См. питфолл про `429` ниже. +## 🔑 ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker: капча ПРИВЯЗАНА К СЕССИИ + +Самый запутанный пункт. Дефект выглядел как «неверный пароль», потом как «капча», +на самом деле — **капча выдаётся только для «холодных» сессий**. + +Замеры в одном ходе (скрипты `/tmp/fs_session_cmp.py`, `/tmp/fs_search_check.py`): + +``` +A: request.post /forum/login.php БЕЗ session → len=13 335 ❌ форма логина вернулась +B: request.post /forum/login.php С session=prowlarr → len=251 792 ✅ ЗАЛОГИНЕН +C: request.get tracker.php?nm=...&f=... в той же сессии → len=254 745 ✅ выдача + auth_failed_in_html=False, login_form=False +``` + +🔴 **Вывод: логин через сессию `prowlarr` РАБОТАЕТ.** Капча отдаётся только новым +(безымянным) сессиям — то есть `PROXY_URL` + переиспользование сессии `prowlarr` её обходят. +Мой одиночный тест без сессии давал 13 KB и порождал ложный диагноз «капча блокирует всё». + +**Как проверить состояние RuTracker правильно:** +```python +# ВСЕГДА с session=prowlarr, иначе получишь ложную капчу +{"cmd":"request.post","url":"https://rutracker.org/forum/login.php", + "postData":"login_username=...&login_password=...&login=...", + "session":"prowlarr","maxTimeout":240000} +``` +Признак «залогинен» — **len ≈ 250 KB**, формы нет. 13 KB = сессия холодная, а не «пароль плох». + +> ⚠️ **Не делать вывод о пароле по тесту БЕЗ сессии.** Всегда `session=prowlarr`. + +### Как снялся карантин RuTracker (рабочая процедура) + +`health`/`indexerstatus` держат **кэш** (`disabledTill`), даже когда трекер уже отвечает. +Снятие — **тем же тестом полным объектом**, что и для Kinozal: +```bash +docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexer/1 > /tmp/p1.json +docker cp /tmp/p1.json prowlarr:/tmp/p1.json +docker exec prowlarr curl -s -X POST -H "X-Api-Key: $PK" -H "Content-Type: application/json" \ + --data-binary @/tmp/p1.json http://localhost:9696/api/v1/indexer/test +# → {} с HTTP=200 = карантин снят +docker exec prowlarr curl -s -H "X-Api-Key: $PK" http://localhost:9696/api/v1/indexerstatus # → [] +docker exec prowlarr curl -s -o /dev/null -w "%{http_code}" "http://localhost:9696/1/api?t=caps&apikey=$PK" # → 200 +``` +Проверено: `{}` + **200** → `indexerstatus` пуст, `caps` → **200**. + ## ✅ ЗАКРЫТО: пароль RuTracker — рабочий (первый диагноз был НЕВЕРЕН) **Итог 2026-09-28 (позже в тот же вечер):** сохранённая в Prowlarr пара @@ -401,6 +446,44 @@ IP-литералы. Отсюда же следствие: после правк ⚠️ Откат: env-вариант убран из compose (бэкап `~truenas_admin/docker-compose.yml.bak-20260928-lidarr-proxy`). +## ✅ ЗАКРЫТО: Lidarr — путь загрузки настроен (`musicCategory`) + +Отдельный дефект, найден позже в тот же вечер. Вопрос Alex: «Lidarr при добавлении будет +качать в музыку?» — ответ был **нет**, и это подтвердилось фактами. + +**Было (сломано):** +``` +musicCategory = "" ← пусто! +musicDirectory = "" +musicImportedCategory= null +``` +Следствие: Transmission получил бы задачу **без категории**, положил файл плоско в +`/mnt/storage/Downloads`, а Lidarr ждал бы его в `/storage/Downloads/<категория>`. +Скачивание прошло бы — **импорт в библиотеку упал**. + +**Стало (рабочий путь, проверено):** +``` +Lidarr musicCategory = lidarr ← PUT ?forceSave=true → 202 +Transmission: /mnt/storage/Downloads/lidarr ✅ существует (abc:abc) +Lidarr: /storage/Downloads/lidarr ✅ существует +RemotePathMapping: /mnt/storage/Downloads/ → /storage/Downloads/ ✅ +rootFolder: /storage/Music (978 GB free, accessible) ✅ +Скачается в: /storage/Music// ✅ +Поиск релизов: 43 FLAC-раздачи (seeders 6/5/7) ✅ +``` + +🔴 **`musicCategory` — дефолт `lidarr`** (не `music`!). Проверять по schema +(`downloadclient/schema` → implementation `Transmission`) и сверять с реально +существующим каталогом в Transmission. Radarr по той же схеме использует `radarr`, +Sonarr — `sonarr`; каталоги `/mnt/storage/Downloads/{lidarr,radarr,sonarr}` уже созданы. + +Скрипт: `/tmp/lidarr_category.py` (GET downloadclient/1 → правка `musicCategory` → PUT `?forceSave=true` → 202 → read-back). +⚠️ У полей бывает **нет ключа `value`** (`musicDirectory` = `''` без `value`) — не падать +на `f['value']`, использовать `f.get('value')`. + +> ⚠️ **`monitored=false`** у добавленного артиста — Lidarr не начнёт качать, пока +> у артиста не включён мониторинг альбомов (`Lidarr → Artist → Monitor`). + ## 🔴 ПИТФОЛЛ: `test` требует ПОЛНЫЙ объект, не `{id}` → 400 Во **всех** arr-сервисах (`Prowlarr`, `Radarr`, `Sonarr`, `Lidarr`) эндпоинт @@ -483,12 +566,21 @@ localhost,127.0.0.1,vless-proxy,prowlarr,lidarr,radarr,sonarr,transmission,jelly - **~16:20** — карантин Kinozal/Kinozal(M) снят тестом полным объектом → `caps` 1/5/6 → 200. Radarr/Sonarr: `PUT ?forceSave=true` → 202, `docker restart` → `health` **`[]`**. - **~16:40** — RuTracker перестал логиниться: HTML сжался **251 KB → 13 KB**, в форме - найден `cap_code` + метка `Код:` → **трекер требует капчу**. Пара в Prowlarr - **не менялась** (сверено байт-в-байт с локальной копией) — диагноз «пароль неверен» ложный. -- **Итог:** инфраструктура Тайги чиста (Prowlarr/Radarr/Sonarr `health=[]`, Lidarr работает). - Открыты **2 дефекта на стороне самих трекеров**: капча RuTracker (нужен ручной вход Alex - браузером через тот же IP прокси) и категории RuTor (`no results in the configured - categories` — трекер не отдаёт фильмы/сериалы). + найден `cap_code` + метка `Код:` → диагноз «трекер требует капчу». + Пара в Prowlarr **не менялась** (сверено байт-в-байт с локальной копией) — «пароль неверен» ложный. +- **~17:00** — Alex сам починил логин на трекере. Проверка выявила **ключевое**: + логин БЕЗ сессии → 13 KB (капча), логин **С `session=prowlarr`** → **251 792** ✅. + Капча привязана к «холодной» сессии; сессия Prowlarr её обходит. См. раздел + «ГЛАВНОЕ ОТКРЫТИЕ ПРО RuTracker». +- **~17:10** — найден отдельный дефект Lidarr: `musicCategory` **пустая** → импорт + скачанного упал бы. Исправлено на `lidarr` (202); сверены каталоги, маппинг, root folder. + Поиск релизов: **43** FLAC-раздачи. +- **~17:20** — карантин RuTracker снят тестом полным объектом → `{}` HTTP **200**, + `indexerstatus` → `[]`, `caps` idx1 → **200**. Prowlarr полностью чист. +- **Итог:** инфраструктура Тайги чиста и проверена. Открыт **1** дефект — RuTor + (`no results in the configured categories`, на стороне трекера). Остаток-механика: + `docker restart radarr sonarr lidarr` для сброса **кэша health** со старым RuTracker + (команда ждала апрува Alex, в этой сессии не выполнена). ### Что делать при возврате симптома «индексера недоступны»