mcp: closing a session right after a cancelled call drops notifications/cancelled, so the server handler keeps running

Đang mở
  • Có gì không ổn?
#1,505 1 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

@vshalpnjabi đang làm issue này rồi.

Từ ngày 6/11/2026.

  • #1 của @vshalpnjabi — đã đóng, không merge
  • #1508 của @vshalpnjabi — đã đóng, không merge

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/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ệ
go
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Start by tracing call() and ClientSession.Close through the JSON-RPC connection shutdown path, then inspect how outgoing notifications are tracked and drained. The issue’s repro can confirm the failure and provide a starting test. Done means closing immediately after a cancelled call still delivers notifications/cancelled, cancels the server handler, and avoids waiting for the 5-second timeout.

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

Mô tả

Summary

Since v1.8.0 (#1151), call() retires a cancelled call and sends notifications/cancelled from a goroutine. If the client closes the session right after the call returns (a graceful shutdown that cancels in-flight tool calls and then closes, for example), the notification is dropped. On a stateful streamable HTTP server the tool handler is then never cancelled, and ClientSession.Close blocks for closeDeleteTimeout (5s).

MCPGODEBUG=blockingcancelnotify=1 restores the v1.7.0 ordering, but it is scheduled for removal in v1.9.0.

Repro (v1.8.0, also matches main)
package repro

import (
	"context"
	"errors"
	"net/http"
	"net/http/httptest"
	"testing"
	"time"

	"github.com/modelcontextprotocol/go-sdk/mcp"
)

func TestCloseAfterCanceledCallCancelsTheServerHandler(t *testing.T) {
	entered := make(chan struct{}, 1)
	canceled := make(chan struct{}, 1)
	release := make(chan struct{})

	server := mcp.NewServer(&mcp.Implementation{Name: "server", Version: "1"}, nil)
	server.AddTool(&mcp.Tool{Name: "wait", InputSchema: map[string]any{"type": "object"}},
		func(ctx context.Context, _ *mcp.CallToolRequest) (*mcp.CallToolResult, error) {
			entered <- struct{}{}
			select {
			case <-ctx.Done():
				canceled <- struct{}{}
				return nil, ctx.Err()
			case <-release:
				return &mcp.CallToolResult{}, nil
			}
		})
	httpServer := httptest.NewServer(mcp.NewStreamableHTTPHandler(func(*http.Request) *mcp.Server { return server }, nil))
	t.Cleanup(httpServer.Close)
	t.Cleanup(func() { close(release) })

	client := mcp.NewClient(&mcp.Implementation{Name: "client", Version: "1"}, nil)
	session, err := client.Connect(t.Context(), &mcp.StreamableClientTransport{Endpoint: httpServer.URL}, nil)
	if err != nil {
		t.Fatal(err)
	}

	ctx, cancel := context.WithCancel(t.Context())
	go func() {
		<-entered
		cancel()
	}()
	if _, err := session.CallTool(ctx, &mcp.CallToolParams{Name: "wait"}); !errors.Is(err, context.Canceled) {
		t.Fatalf("CallTool: got %v, want context.Canceled", err)
	}

	start := time.Now()
	_ = session.Close()
	closed := time.Since(start)

	select {
	case <-canceled:
		t.Logf("handler canceled; Close took %v", closed.Round(time.Millisecond))
	case <-time.After(2 * time.Second):
		t.Fatalf("server handler never saw the cancellation; Close took %v", closed.Round(time.Millisecond))
	}
}

Go 1.26.10, linux/amd64:

  • Default: fails 20/20, server handler never saw the cancellation; Close took 5s.
  • MCPGODEBUG=blockingcancelnotify=1: passes 20/20, handler canceled; Close took 1ms.
Why
  1. call() runs conn.Retire(call, ...), starts the notify goroutine and returns.
  2. ClientSession.Close → jsonrpc2.Connection.Close marks the connection closing.
  3. The goroutine's Notify finds no outgoing calls and no incoming requests, so shuttingDown(ErrClientClosing) rejects it. The notification is never written.
  4. The streamable client sends DELETE. serveStatefulDELETE → ServerSession.Close cancels only subscriptions/listen handlers, then conn.Close waits for in-flight requests, including the tool handler that is still blocked on its context.
  5. The DELETE hangs until the client gives up after closeDeleteTimeout and cancels its connection. The handler keeps running.

So closing the connection does not signal the cancellation to a stateful streamable server, which is the assumption in #1241.

Suggestion

Keep the caller's return immediate (the point of #1150), but register the pending notification synchronously before call() returns, e.g. bump outgoingNotifications (or an equivalent "pending cancel" counter) before spawning the goroutine. Then Close allows the write and its drain waits for it, bounded by notifyCancellationTimeout.

We hit this in a graceful-shutdown path that cancels tool calls, waits for them to return, then closes the session; we're running with blockingcancelnotify=1 until there is a fix.

Ngôn ngữ chính
Go
Star
5.3k
Fork
607
Merge trung bình
1 ngày 11 giờ
Pull request đã merge (30 ngày)
82

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

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

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/go-sdk

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

Issue tương tự

Thêm issue về Go

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.