streamable client: Connect blocks far past its context deadline against an unresponsive server (detached-context cleanup)

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

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

Từ ngày 5/9/2026.

  • #1241 của @arpankernel — đang mở

Đá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
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu trong mcp/streamable.go, xung quanh phần triển khai StreamableClientTransport.Connect gần dòng 2045, sau đó theo dõi quá trình dọn dẹp sau khi khởi tạo thất bại. Chạy bản tái hiện được cung cấp TestConnectOvershootsDeadline để quan sát độ trễ. Được xem là hoàn tất khi Connect trả về xấp xỉ vào deadline của caller, ngay cả khi server chấp nhận các kết nối nhưng không bao giờ phản hồi, cùng với kiểm thử hồi quy cho hành vi đó.

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

Mô tả

needs investigation
What

Client.Connect with a context deadline can block far past that deadline against a server that accepts TCP connections but never responds (black-holed peer). Observed: a 2s deadline returns after ~12s with the default HTTP client in a local test; in production, with connections crossing a NAT that silently dropped packets, a 10s deadline stretched to ~125s (kernel TCP timeout).

The caller's deadline bounds the initialize request itself, but not the error-path cleanup that follows. StreamableClientTransport.Connect detaches the incoming context for the connection's lifecycle (connCtx, cancel := context.WithCancel(xcontext.Detach(ctx)), mcp/streamable.go ~L2045 in v1.7.0). That detachment is intentional and documented for keeping the standalone SSE stream alive past a short connect deadline. However, when initialize fails at the deadline, the cleanup work that runs before Connect returns (the notifications/cancelled write for the abandoned call and session.Close()) issues HTTP requests bound to the detached connection context, not to the caller's expired one. Against a black-holed server those requests block until the HTTP transport or the kernel gives up, so Connect overshoots its deadline by minutes with a default http.Client (no ResponseHeaderTimeout).

Related: #1183 covers the same detached-context ordering problem for Close() specifically. This report is about Connect not honoring its own deadline on the error path.

Repro
func TestConnectOvershootsDeadline(t *testing.T) {
	// Accepts TCP connections, never responds to any request.
	ln, err := net.Listen("tcp", "127.0.0.1:0")
	if err != nil {
		t.Fatal(err)
	}
	defer ln.Close()
	go func() {
		for {
			conn, err := ln.Accept()
			if err != nil {
				return
			}
			defer conn.Close()
		}
	}()

	client := mcp.NewClient(&mcp.Implementation{Name: "c", Version: "0"}, nil)
	tr := &mcp.StreamableClientTransport{Endpoint: "http://" + ln.Addr().String()}
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
	defer cancel()

	start := time.Now()
	_, err = client.Connect(ctx, tr, nil)
	elapsed := time.Since(start)
	t.Logf("Connect returned after %s, err=%v", elapsed, err)
	if elapsed > 4*time.Second {
		t.Fatalf("Connect blocked %s past a 2s deadline", elapsed)
	}
}

With go-sdk v1.7.0 and Go 1.24 this fails: Connect returned after 12.03s, err=context deadline exceeded; sending "notifications/cancelled": rejected by transport: Post "http://127.0.0.1:...": context deadline exceeded.

Expected

Connect(ctx, ...) returns within (approximately) ctx's deadline regardless of server behavior. Error-path cleanup for a session that never initialized could be best-effort/asynchronous, or bounded by the caller's context rather than the detached connection context.

Workaround

We now run Connect+ListTools in a goroutine and select on the deadline, abandoning the goroutine on timeout, plus a cloned http.Transport with ResponseHeaderTimeout and a short dial timeout (https://github.com/coder/coder/pull/28400).

🤖 Filed by Mux (AI agent) on behalf of @ibetitsmike.

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

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.