vvzvlad/gitmost

feat(ai-chat): устойчивость тулов — parts-валидация + MCP in-run recovery + write-class ретрай (#489) #508

Open

agent_coder wants to merge 5 commits from feat/489-tool-resilience into feat/487-terminal-lifecycle

Author	SHA1	Message	Date
agent_coder	791a707eb6	docs(ai-chat): задокументировать поверхность #489 — env-var, устаревшая заметка, CHANGELOG F1 (ревью #508): - .env.example: новая AI_MCP_SSE_BODY_TIMEOUT_MS (дефолт 600000, 10 мин) — bodyTimeout SSE-транспорта external-MCP; idle между тул-вызовами легитимен. - .env.example: поправлена ставшая ложной заметка про AI_MCP_STREAM_TIMEOUT_MS (SSE-idle-между-вызовами больше не режется им — с #489 это отдельная var; 1-мин silence остаётся только для HTTP/headers и одиночного залипшего вызова). - CHANGELOG [Unreleased]/Fixed: битый part больше не 500-ит каждый ход + не плодит дубль user-строки; MCP-транспорт-дропы восстанавливаются in-run (readOnly ретраится раз, write никогда) + новая env-var. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 09:11:32 +03:00
agent_coder	60205398bb	test(ai-chat): застабить findAllByChat в lifecycle-моке под convert-before-insert (#489 ) Коммит 1 (#489) прогоняет загрузку истории + convertToModelMessages ДО insert user-строки (convert-before-insert, чтобы ретрай не плодил дубли), поэтому stream() теперь зовёт реальный метод репо findAllByChat перед insert. Хэнд-роллед мок в тесте «exception after beginRun → settled to error» стабил только insert, и тест ловил «findAllByChat is not a function» вместо «insert boom». Порядок инварианта НЕ изменился: и findAllByChat, и insert идут ПОСЛЕ beginRun (reconcileChat между ними — best-effort, глотает ошибку), так что бросок по- прежнему происходит ПОСЛЕ начала рана и обязан сеттлить ран в error. Застабил findAllByChat → [] (реальный репо-метод, см. ai-chat.controller.ts), тест снова доходит до insert boom и проверяет settle-to-error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 08:25:29 +03:00
agent_coder	38a09c5ca1	fix(ai-chat): write-class-ретрай только для доверенного внутреннего Docmost-сервера (#489 ревью) MEDIUM (реальная брешь): SHARED_TOOL_WRITE_CLASS — имена ТУЛОВ Docmost, но mergeNamespaced применял мапу к тулам ЛЮБОГО стороннего MCP-сервера по совпадению rawName. Сторонний WRITE-тул, названный как Docmost-read (getPage/listPages/…), наследовал readOnly → авто-ретрай при транспортной ошибке → double-apply (класс #435). Гарантия «unknown third-party → write → не ретраится» была ЛОЖНОЙ при коллизии имён. Фикс: write-class мапа применяется ТОЛЬКО к серверу, про который известно, что это внутренний Docmost-MCP (isInternalDocmostServer). Сейчас это ВСЕГДА false — в этом пути нет встроенного/доверенного Docmost-сервера: все ai_mcp_servers суть сторонние admin-конфиги, а собственные тулы Docmost идут отдельным in-app путём (docmostTools), не через mcp-clients. Значит НИ ОДИН сторонний тул не получает readOnly по коллизии и не авто-ретраится (undefined → трактуется как write). Мапа грузится лениво только если есть доверенный сервер (иначе ESM-импорт пропускается). isInternalDocmostServer — метод-сим, флипается при появлении доверенного сервера (kind/isBuiltin-колонка или сконфигурённый self-MCP URL). LOW: reconnect не наблюдает composed abort во время 5-сек handshake — задокумен- тировано (окно поздней отмены ≤5s, сокет закрывается на turn-end); проброс composed в общий CAS-дедуплицированный reconnect намеренно НЕ сделан (отменил бы реконнект, нужный конкурентному живому вызову). Тест: сторонний WRITE-тул с именем getPage при транспортной ошибке НЕ ретраится; mutation-verify — форсирование trusted делает тест красным (чужой getPage ретраится). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 08:01:33 +03:00
agent_coder	1b05224b27	fix(ai-chat): MCP-кэш — in-run восстановление, ретраи только для readOnly (#489 ) Кэш внешних MCP-клиентов не делал health-check/reconnect-on-error: после разрыва SSE-транспорта (bodyTimeout режет при тишине МЕЖДУ вызовами) отдавал труп до конца TTL, а модель жгла шаги на ретраях ВНУТРИ текущего рана. - Новое поле writeClass ('readOnly'\|'write') на КАЖДОМ SHARED_TOOL_SPEC + registration-time assert (и compile-time через satisfies). Все 48 спеков расклассифицированы: чтения → readOnly, любая мутация страницы/коммента/шэра/ диаграммы → write. Экспортированы SHARED_TOOL_WRITE_CLASS + isRetryableWriteClass. - Per-run обёртка восстановления транспорта: при транспортной ошибке readOnly-тул реконнектит свой сервер и ретраит РОВНО 1 раз ВНУТРИ рана; write-тул НЕ авторетраится (indeterminate — «могло примениться, проверь», класс инцидента #435). CAS-своп байндинга по identity (проигравший конкурентный вызов ретраит на текущем клиенте, не минтит второй). Лизы не освобождаются mid-run — ран копит set (старая+новая) и релизит на turn-end. - Проверка abortSignal ПЕРЕД ретраем И ПЕРЕД чеканкой свежего клиента; per-call cap покрывает оба attempt'а + connect. - Классификация транспортной ошибки по РЕАЛЬНЫМ шейпам undici (SocketError/ BodyTimeoutError, cause-цепочка), не по мок-ошибкам. - Отдельный, поднятый bodyTimeout для SSE-транспорта MCP (тишина между вызовами легальна) — DEFAULT 10 мин, AI_MCP_SSE_BODY_TIMEOUT_MS. write-class map грузится в mcp-clients лениво через dynamic import (пакет ESM), type-only импорт — без static require ESM из commonjs. Тесты на РЕАЛЬНЫХ error-шейпах: «повтор после обрыва ВНУТРИ рана получает живой клиент», «write-тул не авторетраится», «ретрай после Stop не происходит», + writeClass-контракт в mcp node --test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 08:01:33 +03:00
agent_coder	b50b32bf64	fix(ai-chat): валидация клиентских parts + insert после конвертации (#489 ) Юзер-сообщение персистилось в metadata БЕЗ валидации и реплеилось через convertToModelMessages на каждом ходе; insert user-строки шёл ДО конвертации. Битая структура parts (например, null-элемент в массиве) → конвертация кидает → 500 на КАЖДОМ ходе навсегда, а каждый ретрай добавлял дубль user-строки. - Санитизация parts при приёме: whitelist { text }, прочее (в т.ч. tool-part в input-available) отбрасывается с warn — не попадает в metadata. - convertToModelMessages прогоняется ДО insert'а user-строки (ретрай не плодит дубли); при падении на СТАРОЙ истории — per-row конвертация изолирует битую строку и деградирует её до plain-text с маркером «[tool context omitted]» (молчаливая потеря tool-контекста недопустима). Тесты против РЕАЛЬНОГО convertToModelMessages (null-part реально кидает): unit трёх веток + сервис-регресс «чат с битым сообщением в истории работает, маркер доходит до модели, одна user-строка». Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 08:01:33 +03:00