') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); fix(client): reject stdio send() when the write fails instead of waiting for 'drain' by ondraulehla · Pull Request #2552 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

fix(client): reject stdio send() when the write fails instead of waiting for 'drain' - #2552

Open
ondraulehla wants to merge 1 commit into
modelcontextprotocol:mainfrom
ondraulehla:fix/stdio-client-send-write-callback
Open

fix(client): reject stdio send() when the write fails instead of waiting for 'drain'#2552
ondraulehla wants to merge 1 commit into
modelcontextprotocol:mainfrom
ondraulehla:fix/stdio-client-send-write-callback

Conversation

@ondraulehla

@ondraulehlaondraulehla commented Jul 26, 2026

Copy link
Copy Markdown

StdioClientTransport.send() now settles from the write() callback, so a backpressured send can't stay pending forever when the pipe to the server dies.

Motivation and Context

I noticed this while reading the two stdio transports side by side. The server one rejects a failed write, the client one has no error path at all: its promise executor only takes resolve, and a backpressured write resolves on 'drain'. If the server process then exits, or close() escalates to SIGTERM and SIGKILL, the stream is destroyed, and a destroyed stream never drains. The promise just stays pending, and the 'drain' listener is never removed.

The symptom is that await client.notification(...) never comes back. The notification path awaits the send with no timeout, and the connection-closed teardown settles pending responses but not pending sends, so nothing rescues it. I tried it against a server that answers initialize, stops reading stdin and exits, with 8 MB in flight: the await is still pending after 8 seconds, and with this change it rejects in 0.4 seconds. Requests were already covered by the teardown, so for them the only difference is that they now report the actual EPIPE instead of a generic connection-closed error.

You need a write the pipe won't take in one go to get there, which on Linux is between 160 KB and 224 KB depending on the Node version. Base64 image payloads and file contents in tool arguments reach that routinely.

The server transport has rejected on a write failure since #1568, with a test pinning its listener cleanup, so this brings the client side in line. The fast path stays as it was, since a write() that returns true still resolves right away and only the failure path differs.

How Has This Been Tested?

  • New test in packages/client/test/client/stdio.test.ts, using a server that never reads stdin and then exits with 8 MB of params in flight. Without the change the send never settles and the test reports hung; with it the send rejects and no 'drain' listener is left behind, which is the same leak check the server transport test already makes. I bounded the wait so the old behaviour fails fast instead of timing out the suite, and I don't assert the rejection reason because it is platform specific.
  • On Ubuntu the client suite is green on Node 20, 22 and 24, and pnpm test:all is green on Node 24. I also ran the new test ten times to make sure it isn't flaky. Typecheck, eslint and prettier are clean, changeset included.

Breaking Changes

None. send() already returns Promise<void> and the sibling stdio transport rejects it on a write failure, so callers that awaited it keep working.

v1.x has the same pattern in src/client/stdio.ts, and in src/server/stdio.ts too since #1568 only landed on main. Happy to send that separately if you want it.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

@ondraulehla
fix(client): settle stdio send() from the write callback
25eab69
A backpressured `StdioClientTransport.send()` waited for a `'drain'` event, but
a pipe destroyed by the server process exiting never drains, so the promise
stayed pending for the lifetime of the process and the `'drain'` listener
leaked. Settle from the `write()` callback instead, which Node invokes on flush
or on failure, so the send rejects with the underlying write error. This is what
`StdioServerTransport.send()` already does for its own stdout.
@ondraulehla
ondraulehla requested a review from a team as a code ownerJuly 26, 2026 19:47
@changeset-bot

changeset-botBot commented Jul 26, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 25eab69

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages
NameType
@modelcontextprotocol/clientPatch
@modelcontextprotocol/corePatch
@modelcontextprotocol/serverPatch
@modelcontextprotocol/server-legacyPatch
@modelcontextprotocol/codemodPatch
@modelcontextprotocol/core-internalPatch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@pkg-pr-new

pkg-pr-newBot commented Jul 26, 2026

Copy link
Copy Markdown

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2552

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2552

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2552

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2552

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2552

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2552

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2552

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2552

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2552

commit: 25eab69

@ondraulehla

ondraulehla commented Jul 28, 2026

Copy link
Copy Markdown
Author

Now that 2.0.0 is out, this sits in a released package rather than in a prerelease. @modelcontextprotocol/client@2.0.0 ships the 'drain'-only send at dist/stdio.cjs:208, and the v1 line has the same shape in @modelcontextprotocol/sdk@1.30.0 at dist/cjs/client/stdio.js:196.

Nothing has changed on my side since I opened this. The branch is seven commits behind main but still mergeable, packages/client/src/client/stdio.ts has not been touched since #2514, and the changeset is a patch on the client. I re-checked against main at cc4b416: without the change the regression test still reports the hang, with it the client suite is green (33 files, 798 tests).

@ondraulehlaondraulehla mentioned this pull request Jul 29, 2026
Draft
9 tasks
This was referenced Aug 11, 2026
Open
Open
Open
Open
@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@ondraulehla