test(@modelcontextprotocol/node): cover pre-read body pattern in stateless mode#2026
test(@modelcontextprotocol/node): cover pre-read body pattern in stateless mode#2026Zelys-DFKH wants to merge 3 commits into
Conversation
|
@modelcontextprotocol/client
@modelcontextprotocol/codemod
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/fastify
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
9f10aeb to
39164fd
Compare
|
The Node 20 failure is in The cloudflare workers test connects successfully (the |
Wrangler on Node 20 accepts the initialize handshake before it can reliably handle subsequent requests. The previous retry loop only wrapped connect(), so a successful connect followed by a failed callTool() still caused the test to fail. Extend the loop to retry the full interaction (connect + callTool + assertion) and close the client on each failed attempt before retrying.
…eless mode Add a test for the handleRequest(req, res, parsedBody) overload in stateless mode: drain the IncomingMessage body upstream (body-parser pattern), pass it as parsedBody, and verify that both an initialize request and a subsequent tools/list request succeed on the same reused transport. Found while investigating modelcontextprotocol#1994. In v2 the _hasHandledRequest reuse restriction was removed, so both requests succeed. This test pins that. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
39164fd to
de450db
Compare
Closes #1994 (partial; #1995 handles the v1.x production fix)
The
handleRequest(req, res, parsedBody)overload exists for body-parser users: drain the stream first, then pass the parsed body. It's documented in the JSDoc with an Express example. The stateless describe block had no test covering that pattern, so it was possible to break it without anyone noticing.This adds one. An initialize request followed by a
tools/listrequest, both with the body pre-read viafor awaitand handed off asparsedBody. The second request is what was missing.I found this while digging into #1994. The v1.x issue was a real bug (
_hasHandledRequestthrew on the second request and produced an opaque 500). In v2 that restriction was removed entirely, so both requests succeed fine. This test makes sure it stays that way.Test plan