[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

2026-09-28 15:24:26 +06:00
1 parent 5f3bdf6bff
commit f3dacaaa39
@@ -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`
@@ -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/<Artist>/                           ✅
+Поиск релизов: 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, в этой сессии не выполнена).

 ### Что делать при возврате симптома «индексера недоступны»