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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#3,136 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@mariano-aguero đang làm issue này rồi.

Từ ngày 30/10/2026.

  • #3137 của @mariano-aguero — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
82/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Bắt đầu tại packages/server/src/server/createMcpHandler.ts, ở createLegacyStatelessFallback quanh các dòng được trích dẫn 342–360, và so sánh cách xử lý hủy với PerRequestHTTPServerTransport.handleMessage. Issue mô tả lỗi và một cách khắc phục có thể áp dụng; hoàn thành nghĩa là một yêu cầu bị hủy trước khi đăng ký sẽ đóng transport và hủy ctx.mcpReq.signal, giống như một yêu cầu bị hủy sau đó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
13.7k
Fork
2.4k
Merge trung bình
2 ngày 7 giờ
Pull request đã merge (30 ngày)
26

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/typescript-sdk

Tất cả issue của modelcontextprotocol/typescript-sdk

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.