Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#544 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@mglaman arbeitet bereits daran.

Seit 07.10.2026.

  • #556 von @mglaman — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
php
Bereich
backend-api-design

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
PHP
Sterne
1.6k
Forks
177
Ø Merge
3 T. 1 Std.
Gemergte PRs (30 T.)
27

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modelcontextprotocol/php-sdk

Alle Issues in modelcontextprotocol/php-sdk

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.