Bound client-suite concurrency for timing-sensitive SSE checks

Đang mở
#500 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đá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
55/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
cli, testing-qa, tooling

Hướng nghiên cứu

Bắt đầu từ điểm vào của trình chạy bộ kiểm thử phía client cho --suite all và theo dõi cách sse-retry được khởi chạy, cách các kết quả được sắp xếp và cách checks.json được ghi. Chạy kịch bản độc lập và toàn bộ bộ kiểm thử để xác lập hành vi hiện tại về thời gian và thoát. Công việc được hoàn tất khi tính đồng thời có giới hạn và tính cô lập vẫn bảo toàn việc chọn bộ kiểm thử, thứ tự, cách xử lý lỗi dự kiến, trạng thái tổng hợp và các hiện vật kết quả.

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

Mô tả

The client suite starts every selected scenario at once with Promise.all. With @modelcontextprotocol/conformance@0.2.0-alpha.11, --suite all starts 44 client processes together.

That makes the sse-retry check sensitive to load from the suite itself. The server sends retry: 500, and the client schedules a 500 ms timer. The check measures from the server closing the stream until the server handles the reconnect, so the result also includes event-loop delay and local HTTP dispatch.

The current thresholds pass at 450 to 700 ms and report a warning from 700 to 1000 ms. The warning says the delay is acceptable, but the suite runner treats any warning as an unexpected failure.

This happened in modelcontextprotocol/typescript-sdk#2757: sse-retry reported 2 passes, 0 failures, and 1 warning, which failed the client-conformance job. The OAuth code in that PR does not change SSE reconnect behavior.

I reproduced the same result without changing the client's requested delay. I kept the 500 ms timer and added controlled event-loop work near its deadline. The timer fired at 753 to 754 ms, reconnect and Last-Event-ID checks passed, and the runner produced the same warning and nonzero exit. The isolated scenario and three fresh full-suite runs passed locally at 502 to 505 ms. This does not prove the failed CI run hit the same warning branch because that run did not retain checks.json, but it shows that a correct retry timer can fail under scheduling pressure.

Could the harness support:

  • a bounded --concurrency <n> option for client suites;
  • a repeatable way to isolate wall-clock-sensitive scenarios such as sse-retry from the concurrent pool;
  • the same authoritative suite selection, result order, expected-failure reconciliation, and aggregate exit status as today;
  • detailed result artifacts even when a suite fails?

I do not think sse-retry should be added to the expected-failures baseline or given looser timing assertions. Those choices would hide real reconnect regressions. The goal is to keep the check while removing load created by its own test runner.

Ngôn ngữ chính
TypeScript
Star
127
Fork
101
Merge trung bình
6 ngày 1 giờ
Pull request đã merge (30 ngày)
7

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

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/conformance

Tất cả issue của modelcontextprotocol/conformance

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.