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

StdioServerTransportProvider should support a stdin-close callback without interrupting shutdown

Ouverte
  • Quelque chose ne va pas ?
#936 0 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Calme
Stack technique
java
Domaine
backend

Piste de recherche

Commencez par StdioServerTransportProvider, en particulier par la boucle de lecture de stdin et la gestion de la terminaison de handleIncomingMessages(). Ajoutez ensuite le test de régression suggéré pour piped-stream, puis vérifiez que le callback s’exécute après le nettoyage de session et de inbound-sink, avant la libération du scheduler, et que le thread du callback n’est pas interrompu.

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

Description

waiting for triage

For stdio-based MCP servers, stdin closing is effectively the client disconnect signal. This is especially important when an MCP server runs in a container: once the MCP client disconnects or closes stdin, the server should be able to trigger application shutdown and clean up background resources.

Today, StdioServerTransportProvider closes the MCP session when stdin reaches EOF, but it does not expose a public transport-level callback that applications can use to run shutdown logic.

Downstream, we had to vendor/copy StdioServerTransportProvider to add such a callback.

Current behavior

When the stdin read loop exits, the SDK transport does roughly this:

finally {
  isClosing.set(true);
  if (session != null) {
    session.close();
  }
  inboundSink.tryEmitComplete();
}

The session is closed, but the application has no direct hook to react to the stdio client disconnect.

There is also a subtle ordering issue. handleIncomingMessages() currently disposes the inbound scheduler from doOnTerminate():

this.inboundSink.asFlux()
  .flatMap(message -> session.handle(message))
  .doOnTerminate(() -> {
    this.outboundSink.tryEmitComplete();
    this.inboundScheduler.dispose();
  })
  .subscribe();

When stdin closes, the inbound read loop completes inboundSink. The termination callback can run on the same inbound thread. Disposing the scheduler there may call shutdownNow(), interrupting that same thread before downstream shutdown work has completed.

We observed this downstream: shutdown logic could run with the current thread interrupt flag already set, causing graceful shutdown to fail or exit early.

Expected behavior

StdioServerTransportProvider should allow applications to register an optional callback for stdin EOF / stdio client disconnect.

That callback should run:

  1. After the session is closed.
  2. After the inbound sink is completed.
  3. Before the inbound scheduler is disposed.
  4. Without the current thread being interrupted by scheduler disposal.
Proposed fix

Add an optional callback to StdioServerTransportProvider, for example as a Runnable:

public StdioServerTransportProvider(
    McpJsonMapper jsonMapper,
    InputStream inputStream,
    OutputStream outputStream,
    Runnable closeCallback
)

Or, if a reactive API is preferred:

Supplier<Mono<Void>> closeCallback

Then move inboundScheduler.dispose() out of handleIncomingMessages().doOnTerminate(...) and into the inbound read-loop finally, after the callback has completed.

The inbound read-loop cleanup would look conceptually like this:

finally {
  isClosing.set(true);
  if (session != null) {
    session.close();
  }
  inboundSink.tryEmitComplete();

  if (closeCallback != null) {
    closeCallback.run();
  }

  inboundScheduler.dispose();
}

handleIncomingMessages() should still complete the outbound sink, but should not dispose the inbound scheduler from the termination callback.

Suggested regression test

Add a test that:

  1. Creates a StdioServerTransportProvider with a piped input stream.
  2. Registers a callback.
  3. Starts the transport with a mock session.
  4. Closes the piped output stream to simulate stdin EOF.
  5. Verifies the callback runs.
  6. Verifies Thread.currentThread().isInterrupted() is false inside the callback.
Langage dominant
Java
Étoiles
3.7k
Forks
1.1k
Merge moyen
2 j 5 h
PR mergées (30 j)
4

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

Toutes les issues de modelcontextprotocol/java-sdk

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

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