Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Server][Streamable HTTP] Concurrent SSE streams on one session can consume each other's client responses

Đã đóng
  • Có gì không ổn?
#544 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

Một pull request liên quan đã được merge.

  • #556 của @mglaman — đã 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
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
php
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Start with StreamableHttpTransport::createStreamedResponse() and the getPendingRequests() and checkForResponse() calls described in the issue; trace how yielded request IDs relate to each stream's fiber. Check linked pull request #556, which is already open. Done means concurrent streams on one session cannot consume or time out each other's responses.

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

Mô tả

bug P2 Server

Summary

On Streamable HTTP (handshake era, SSE), two tool calls on one session that both send a server-to-client request, such as elicitation/create, can each receive the other's answer.

Cause

Protocol keeps pending server-to-client requests in one session-wide list, _mcp.pending_requests. The SSE loop in StreamableHttpTransport::createStreamedResponse() walks that whole list, not only the requests its own fiber sent:

$pendingRequests = $this->getPendingRequests($this->sessionId);
// ...
foreach ($pendingRequests as $pending) {
    $response = $this->checkForResponse($pending['request_id'], $this->sessionId);
    if (null !== $response) {
        $yielded = $this->sessionFiber->resume($response);
        // ...

With tool calls A and B open on one session, each waiting in ClientGateway::elicit():

  1. The client answers B's elicitation.
  2. A's loop polls first, finds B's answer, consumes it, and resumes A's fiber with it. A's tool continues with B's answer.
  3. B's answer is gone from the session. B's tool waits until its 120-second timeout.

The timeout branch has the same problem: A's loop can resume A's fiber with a timeout error for B's request ID.

I found this by reading the source on main (a5ed85f) and 0.8.1. I have not reproduced it end to end. Running two streams on one session at the same time needs a server that doesn't serialize requests per session.

Suggested fix

Record which stream sent each pending request, and have each loop check only its own. For example, track the request IDs the fiber yielded in the transport instance, and filter getPendingRequests() by them.

Context

In Drupal's mcp_server we lock the session for the length of a stream. That lock made a second elicitation wait, which hid this bug. We're changing the lock to cover each session write instead of the whole stream, so elicitation answers don't wait on the lease (mcp_server!88). That makes this race reachable.

Ngôn ngữ chính
PHP
Star
1.6k
Fork
177
Merge trung bình
2 ngày 16 giờ
Pull request đã merge (30 ngày)
36

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

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

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

Issue tương tự

Thêm issue về PHP

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.