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

オープン
  • 何か問題がありますか？
#1,505 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@vshalpnjabi がすでに取り組んでいます。

2026年11月6日 から。

  • #1 @vshalpnjabi による — マージされずにクローズ
  • #1508 @vshalpnjabi による — マージされずにクローズ

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Go
スター
5.3k
フォーク
607
平均マージ
1日 11時間
マージ済み PR（30日）
82

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/go-sdk のほかの issue

modelcontextprotocol/go-sdk の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。