Investigate intermittent "Failed to scan response body" errors in streamable-http transport

In the streamable-http transport, MCP servers occasionally log errors such as:

These errors do not currently appear to cause functional issues, but they recur intermittently and may indicate underlying problems in how response bodies are streamed or how connections are closed.

Although they do not look dangerous, it is still worth debugging to determine whether these represent:

• Expected behavior (e.g., client-initiated cancellations),
• Benign but noisy logging, or
• Actual transport-layer bugs such as premature connection closure or race conditions.

Why this matters

• These logs appear across multiple MCP servers, not tied to any specific implementation.
• Cleaning this up will improve observability and ensure reliability of the streamable-http transport.

Next steps

• Reproduce and investigate the conditions under which these errors occur.
• Determine whether logging should be adjusted or if fixes are needed in the transport lifecycle.

Start with the streamable-http transport and reproduce the intermittent “Failed to scan response body” error. Trace response-body streaming and connection closure to determine whether the messages are expected cancellations, noisy logging, or a transport bug; done means the cause is established and the needed logging or lifecycle change is identified.