0.167.51

23.08.2026

Fixed

stdio MCP-серверы убивались сразу после коннекта — регрессия #308 ( — P1; инцидент продакшена 192.168.2.104: gitea MCP в бесконечном цикле transport closed → reconnect, ~1 мёртвый child-процесс в минуту + накопление зомби [gitea-mcp] <defunct>, вызовы тулов падали MCP tool error: mcp call "issue_read" on "gitea": transport error: transport closed). connectBounded из #308 выполняет sess.Connect под attemptCtx = context.WithTimeout(ctx, 60s); этот же ctx уходил в client.Start(ctx), а mcp-go порождает subprocess через exec.CommandContext(attemptCtx, …) — deferred cancel() сразу после успешного коннекта SIGKILL-ил только что подключённый stdio-сервер (Go watchCtx убивает по ctx.Done даже до Wait); следующий ping/вызов получал EOF → «transport closed», health-loop реконнектил — цикл замыкался навсегда. Тесты #308 покрывали только streamable_http. Фикс: client.Start(context.WithoutCancel(ctx)) — время жизни subprocess отвязано от attempt-дедлайна, завершается только штатно через Close() (SIGTERM → SIGKILL); bounded ctx сохранён на handshake (Initialize/SetLevel/ListTools/ListResources/ListPrompts) — гарантия #308 не тронута: зависший stdio-сервер по-прежнему фейлится за bound, failure-путь убивает child через client.Close(). Проверено: привязка ctx к процессу не изменилась в mcp-go вплоть до v1.0.0-beta.1 — фикс необходим на нашей стороне в любой версии. Попутно: апгрейд mark3labs/mcp-go v0.52.0 → v0.58.0 (последняя стабильная; накопленные фиксы Close/zombie/FD-leak в транспортах). Тесты (+2, re-exec паттерн с реальным stdio MCP-сервером): сессия жива и отвечает на Ping ПОСЛЕ cancel и истечения attempt-дедлайна (красный на pre-fix с точной продовой ошибкой «transport closed»); нереагирующий на Initialize stdio-сервер фейлится в пределах bound с DeadlineExceeded в цепочке.