Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#544 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Une pull request liée a déjà été fusionnée.

  • #556 par @mglaman — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
php
Domaine
backend-api-design

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
PHP
Étoiles
1.6k
Forks
180
Merge moyen
3 j 2 h
PR mergées (30 j)
55

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de modelcontextprotocol/php-sdk

Toutes les issues de modelcontextprotocol/php-sdk

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.