[v2] createMcpHandler legacy fallback misses an abort that happens before it subscribes

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#3,136 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mariano-aguero arbeitet bereits daran.

Seit 30.10.2026.

  • #3137 von @mariano-aguero — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
82/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
backend-api-design

Rechercherichtung

Beginne in packages/server/src/server/createMcpHandler.ts bei createLegacyStatelessFallback ungefähr in den zitierten Zeilen 342–360 und vergleiche die Behandlung von Abbrüchen mit PerRequestHTTPServerTransport.handleMessage. Das Issue beschreibt den Fehler und eine mögliche Lösung; als erledigt gilt es, wenn eine Anfrage, die vor dem Abonnement abgebrochen wird, den Transport abbaut und ctx.mcpReq.signal abbricht, so wie es bei einer Anfrage geschieht, die danach abgebrochen wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

v2
What happened?

In the legacy stateless fallback of createMcpHandler, a request whose client aborts before the handler subscribes to request.signal is never seen as aborted. The tool runs with a ctx.mcpReq.signal that never fires, and the transport and server built for that request are only torn down when the tool finishes.

createLegacyStatelessFallback awaits factory() and product.connect(transport), and only then calls request.signal?.addEventListener('abort', teardown, { once: true }). An abort event that already fired is not delivered to a listener added later, and nothing checks request.signal.aborted after subscribing:

https://github.com/modelcontextprotocol/typescript-sdk/blob/39ae8e6192cf43273aaaf2de4169dfa9f7216e28/packages/server/src/server/createMcpHandler.ts#L342-L360

We hit it on a server whose tool waits up to 45 s for a state change and stops early on ctx.mcpReq.signal. A client that dropped the request while auth and the factory were still running left that wait running to its end. On a loaded machine that window was a few hundred ms. Our workaround is to also listen on ctx.http.req.signal in the tool.

What did you expect?

A request aborted before the handler subscribed is handled like one aborted after: teardown runs, the transport closes and ctx.mcpReq.signal aborts. The modern path already does this, since PerRequestHTTPServerTransport.handleMessage checks signal.aborted before dispatching.

A possible fix is to check right after subscribing:

request.signal?.addEventListener('abort', teardown, { once: true });
if (request.signal?.aborted) teardown();
Code to reproduce
import { createMcpHandler, McpServer } from '@modelcontextprotocol/server';

const handler = createMcpHandler(() => {
  const server = new McpServer({ name: 'repro', version: '0.0.0' });
  server.registerTool('wait', { description: 'Waits up to 2 s for the request to be aborted' }, async (ctx) => {
    const started = Date.now();
    const aborted = await new Promise((resolve) => {
      if (ctx.mcpReq.signal.aborted) return resolve(true);
      ctx.mcpReq.signal.addEventListener('abort', () => resolve(true), { once: true });
      setTimeout(() => resolve(false), 2_000);
    });
    console.log(`tool saw the abort: ${aborted}, after ${Date.now() - started} ms`);
    return { content: [{ type: 'text', text: 'done' }] };
  });
  return server;
});

async function call(signal) {
  const request = new Request('http://localhost/mcp', {
    method: 'POST',
    headers: { 'content-type': 'application/json', accept: 'application/json, text/event-stream' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'tools/call', params: { name: 'wait', arguments: {} } }),
    signal,
  });
  // Held for the whole exchange, as a server framework holds it.
  await handler.fetch(request).then((res) => res.text(), () => undefined);
  return request;
}

console.log('client aborts 1 s into the call:');
const late = new AbortController();
setTimeout(() => late.abort(), 1_000);
await call(late.signal);

console.log('client aborted before the handler subscribed:');
await call(AbortSignal.abort());

Output with Node 22.11:

client aborts 1 s into the call:
tool saw the abort: true, after 971 ms
client aborted before the handler subscribed:
tool saw the abort: false, after 2001 ms

The script keeps the Request alive until the response is read. Without that, undici can garbage-collect the original request and its signal stops reaching the clone that classifyEntryRequest forwards, so even the first case never sees the abort. That is unrelated to this issue.

SDK version

@modelcontextprotocol/server 2.3.1. The same code is on main at 39ae8e6 (2.4.0 was not tested).

Area

Server

Vorherrschende Sprache
TypeScript
Sterne
13.7k
Forks
2.4k
Ø Merge
2 T. 7 Std.
Gemergte PRs (30 T.)
26

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/typescript-sdk

Alle Issues in modelcontextprotocol/typescript-sdk

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.