When executing client.close(), onerror will be executed twice (Streamable HTTP)

[shellRaining]

To Reproduce
Steps to reproduce the behavior:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { log } from "console";

const client = new Client(
  {
    name: "comate",
    version: "1.0.0",
  },
  {
    capabilities: {},
  },
);
const transport = new StreamableHTTPClientTransport(
  new URL("https://api.githubcopilot.com/mcp/"),
  {
    requestInit: {
      headers: {
        Authorization: "Bearer xxx",
      },
    },
  },
);
client.onclose = () => {
  log(`close`);
};
client.onerror = (e) => {
  log(`error: ${e.message}`);
};
await client.connect(transport);
await new Promise((resolve) => {
  setTimeout(resolve, 1000);
});

await client.close()

run this code, will occur these log below

close
error: The operation was aborted.
error: The operation was aborted.

Expected behavior
only call onerror for once

[Anil567849]

I tried debugging the code and found that onerror is triggered only once. If my observation is incorrect, could you please provide more details on how to reproduce this issue?

[shellRaining]

Kapture.2025-08-15.at.10.20.35.mp4

my sdk version is 1.17.2, and notice that the github token should replace with yours, or will occur 401 error

[felixweinberger]

Port #880 to v2.

[windro-xdd]

I'd like to take this. I'll port the close-path fix to v2 so abort-triggered transport shutdown doesn't emit duplicate callbacks, and add regression tests covering behavior.

[windro-xdd]

I accidentally sent a malformed previous comment due to shell escaping. Correct plan: I'll port the close-path fix to v2 so abort-triggered Streamable HTTP shutdown does not emit duplicate onerror callbacks, and add regression tests around client.close() behavior.

[azender1]

This feels like a broader execution-boundary issue more than just an event-handler bug.

Once the same logical close / teardown path can emit multiple times, downstream consumers have to guess whether they’re observing:

duplicate signaling
partial completion
or a genuinely new execution path

The pattern I’ve had the best results with is:

define a stable logical operation ID for the action
persist completion / terminal state at the boundary
make retries / repeats return that prior terminal state instead of re-emitting effects

Otherwise a duplicated callback can easily fan out into duplicated cleanup, logging, notifications, or external mutation downstream.