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

Aperta
  • Qualcosa non va?
#1,505 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@vshalpnjabi ci sta già lavorando.

Dal 6/11/2026.

  • #1 di @vshalpnjabi — chiusa senza merge
  • #1508 di @vshalpnjabi — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
5.3k
Fork
607
Merge medio
1g 11h
PR unite (30g)
82

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/go-sdk

Tutte le issue di modelcontextprotocol/go-sdk

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.