Undici instrumentation marks successful MCP requests as aborted due to premature AbortController.abort() in SSE / StreamableHTTP transports

[bhaveshpatel640]

When using the MCP TypeScript SDK (SSEClientTransport / StreamableHTTPClientTransport) with Undici instrumentation (e.g., OpenTelemetry), successful MCP POST requests are being reported as aborted.

This happens because close() immediately calls:

this._abortController?.abort()

If a POST response is still being processed, Undici receives the abort signal and marks the span as an error, even though the server returned 200 OK. This results in spans like:

UND_ERR_ABORTED: The operation was aborted

for successful requests.

---

Impact

• Successful MCP requests show up as failed in traces
• Undici logs aborted errors
• Misleading telemetry in distributed tracing
• Connections stay open until Undici’s idle timeout (~10–14 seconds)

---

Reproduction

1. Enable OTel Undici instrumentation

2. Use SSEClientTransport or StreamableHTTPClientTransport

3. Send any POST request (initialize, callTool, etc.)

4. Immediately call client.close()

5. Observe:

   • Response is 200 OK
   • Undici reports UND_ERR_ABORTED
   • Span is marked as failed

---

Request

Could the SDK:

1. Avoid calling AbortController.abort() while requests are still in-flight
2. Optionally provide a graceful close mode that waits for active requests to finish

This would prevent Undici from misclassifying successful MCP requests as aborted and keep telemetry accurate.

[bhaveshpatel640]

@jspahrsummers @ihrpr

Calling AbortController.abort() in close() seems to mark in-flight 200 OK requests as aborted in Undici/OTel.

Can we take a look at implementing a graceful close here (wait for in-flight requests before aborting)?

[bhaveshpatel640]

@felixweinberger @jspahrsummers @ihrpr

Can we prioritize this by any chance?

[aptsalt]

I'd like to take this. My approach:

Track in-flight send() requests in both SSEClientTransport and StreamableHTTPClientTransport. When close() is called, wait for pending requests to settle (with a 2s timeout to prevent hanging) before calling AbortController.abort().

This means successful POST responses will complete processing before the abort signal fires, so Undici/OpenTelemetry will see the 200 OK instead of UND_ERR_ABORTED. Stuck requests still get cleaned up after the timeout.

PR incoming.