| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix: relay client notifications upstream instead of echoing them back Manual testing of the published 4.0.0-rc.1 against a real server found two defects that six hours of soak across twelve platforms did not. Both stdio bridges classified a stdin frame as request-or-not, and wrote everything that was not a request to stdout — the direction it had just arrived from. So a client's `notifications/initialized` came straight back to that client, and never reached the server. MCP Inspector shows a `SERVER → CLIENT notifications/initialized` on every single connection because of it, and a server sending that notification is not something the protocol allows. The same path returned a client's response to a server-initiated request back to the client, leaving the server waiting, and dropped `notifications/cancelled` so a server kept working on requests its client had abandoned. Notifications and responses now go upstream. `notifications/initialized` is the exception: `Client.connect` sends its own as the last step of the handshake, so relaying the client's copy would deliver a second one to a server that has already seen it. A relay failure is logged rather than thrown, because the client is still connected and its next request deserves an answer. Three existing tests had pinned the old behaviour, one of them describing it as passing frames "straight through". They now assert the frame reaches the server and that nothing is echoed back. Also give a stateful session a default idle timeout of thirty minutes. A session owns a child process and the only thing that released it was the client explicitly deleting the session; a client that crashes, is force-quit, or just closes its transport never sends that, so every such disconnect stranded a process for the lifetime of the gateway. Measured 2 -> 5 children over three connect/disconnect cycles. Thirty minutes is far longer than any gap between calls in a live session and still bounds what a vanished client can leave behind. | 5 天前 | |
fix: preserve UTF-8 across child stdout chunks | 7 天前 | |
fix: answer 404 for a session id the stateful gateway no longer holds Stateful stdio→Streamable HTTP collapsed two different faults into one 400: a request with no `Mcp-Session-Id` header at all, and a request carrying a session id the gateway does not hold. Only the first is a 400. The Streamable HTTP spec makes the second a 404, and that 404 is the only signal a compliant client gets that it should re-initialize: "The server MAY terminate the session at any time, after which it MUST respond to requests containing that session ID with HTTP 404 Not Found. When a client receives HTTP 404 in response to a request containing an Mcp-Session-Id, it MUST start a new session by sending a new InitializeRequest without a session ID attached." Answering 400 leaves the client replaying a dead id until a human restarts it. A client reaches that state after `--sessionTimeout` reaps an idle session, after an explicit DELETE, and across a gateway restart. The status codes themselves are unchanged since 3.4.3, so this is not a regression — but 4.0.0 is the release that makes the path ordinary. Stateful sessions now default to a 30-minute idle timeout (added with the child-leak fix); before that, an unconfigured gateway never terminated a session, so the branch was close to unreachable in practice. Every idle session now expires. Both handlers are covered: the POST chain gains an unknown-session branch returning 404 with JSON-RPC -32001, and the shared GET/DELETE handler splits its `!sessionId || !transports.has(sessionId)` guard so a missing header keeps its 400 while an unknown id gets the 404. Reported in #123 by @springbrookconsultingllc-byte, with fixes proposed in #149 by @jstar0 and #162 by @v8eta; this takes the shape of #162, which covers GET and DELETE as well as POST. | 4 天前 | |
Merge remote-tracking branch 'origin/main' into codex/issue-156-node20 | 7 天前 | |
fix: preserve UTF-8 across child stdout chunks | 7 天前 | |
fix: relay client notifications upstream instead of echoing them back Manual testing of the published 4.0.0-rc.1 against a real server found two defects that six hours of soak across twelve platforms did not. Both stdio bridges classified a stdin frame as request-or-not, and wrote everything that was not a request to stdout — the direction it had just arrived from. So a client's `notifications/initialized` came straight back to that client, and never reached the server. MCP Inspector shows a `SERVER → CLIENT notifications/initialized` on every single connection because of it, and a server sending that notification is not something the protocol allows. The same path returned a client's response to a server-initiated request back to the client, leaving the server waiting, and dropped `notifications/cancelled` so a server kept working on requests its client had abandoned. Notifications and responses now go upstream. `notifications/initialized` is the exception: `Client.connect` sends its own as the last step of the handshake, so relaying the client's copy would deliver a second one to a server that has already seen it. A relay failure is logged rather than thrown, because the client is still connected and its next request deserves an answer. Three existing tests had pinned the old behaviour, one of them describing it as passing frames "straight through". They now assert the frame reaches the server and that nothing is echoed back. Also give a stateful session a default idle timeout of thirty minutes. A session owns a child process and the only thing that released it was the client explicitly deleting the session; a client that crashes, is force-quit, or just closes its transport never sends that, so every such disconnect stranded a process for the lifetime of the gateway. Measured 2 -> 5 children over three connect/disconnect cycles. Thirty minutes is far longer than any gap between calls in a live session and still bounds what a vanished client can leave behind. | 5 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 5 天前 | ||
| 7 天前 | ||
| 4 天前 | ||
| 7 天前 | ||
| 7 天前 | ||
| 5 天前 |