Uh oh!
There was an error while loading. Please reload this page.
Make sure to consume HTTP error response bodies - #1173
Conversation
commit: |
| }; | ||
| const response = await (this._fetch ?? fetch)(this._url, init); | ||
| await response.body?.cancel(); |
There was a problem hiding this comment.
feels weird cancelling the body before checking if response is okay. I'm not super clued up on this I just want to check line 620 will still work as expected.
There was a problem hiding this comment.
Good question.
I think both .ok and .status should still be available on the response objects after cancellation and unaffected by it.
Tried it out with this script:
(async()=>{// Fetch something that returns a bodyconstresponse=awaitfetch('https://httpbin.org/json');console.log('Before cancel:');console.log(' status:',response.status);console.log(' ok:',response.ok);console.log(' headers.content-type:',response.headers.get('content-type'));// Cancel the body streamawaitresponse.body?.cancel();console.log('\nBody cancelled.\n');console.log('After cancel:');console.log(' status:',response.status);console.log(' ok:',response.ok);console.log(' headers.content-type:',response.headers.get('content-type'));// Try to read the body now - this should failconsole.log('\nTrying to read body after cancel:');try{consttext=awaitresponse.text();console.log(' text:',text.substring(0,50));}catch(e){console.log(' ERROR:',e.message);}})();Which gave the following output:
Before cancel:
status: 200
ok: true
headers.content-type: application/json
Body cancelled.
After cancel:
status: 200
ok: true
headers.content-type: application/json
Trying to read body after cancel:
ERROR: Body is unusable: Body has already been read
So this looks good to me.
We could put 2 cancels, one inside the 405 check and then one at the end of the function, but this seems fine.
| // If the response is 202 Accepted, there's no body to process | ||
| if (response.status === 202) { | ||
| await response.body?.cancel(); |
There was a problem hiding this comment.
awesome. This line I have been meaning to add for ages
There was a problem hiding this comment.
this is a script and not part of the sdk. can remove changes to this :)
mattzcarey
left a comment
There was a problem hiding this comment.
One question but strong approval when answered
mattzcarey
commented
Nov 26, 2025
The context for this is that Cloudflare Durable Objects have a 6 simultaneous connection limit which is often reached by MCP clients. This should help us use the full amount with active requests. |
Calling body.cancel() then response.text() would fail because the stream is already closed. Use text() first to consume the body.
This script runs in Node.js at build time, not in Cloudflare Workers, so it doesn't need the body consumption fix.
@mattzcarey pushed some small clean-ups to this branch, feel free to accept and merge if you're happy with it |
mattzcarey
commented
Nov 26, 2025
I think I need a review from the auth team @pcarleton :) |
Uh oh!
There was an error while loading. Please reload this page.
…#1173) Co-authored-by: Eduardo Gomes <egomes@cloudflare.com> Co-authored-by: Felix Weinberger <fweinberger@anthropic.com> Co-authored-by: Felix Weinberger <3823880+felixweinberger@users.noreply.github.com>
body.cancel() can hang indefinitely with certain server responses
(e.g., Sentry MCP's 404). Using text().catch(() => {}) is safer:
- Always completes (reads all data)
- Releases connection (body consumed)
- No stream coordination needed
Tested with Sentry MCP which previously hung on OAuth discovery.
Fixes regression from modelcontextprotocol#1173 while preserving Cloudflare Workers fix.body.cancel() can hang indefinitely with certain server responses
(e.g., Sentry MCP's OAuth flow). Using text?.().catch(() => {}) is safer:
- Always completes (reads all data)
- Releases connection (body consumed)
- No stream coordination needed
- Uses optional chaining for compatibility with mock responses
Fixes regression from modelcontextprotocol#1173 and modelcontextprotocol#1214.
Addresses #1172
Motivation and Context
Fix the errors in Cloudflare workers when multiple requests go inflight without reading response bodies, which are breaking my SDK client flows :(
How Has This Been Tested?
Unit tests and manually tested with Cloudflare workers
Types of changes
Checklist