MCP server using StdioServerTransportProvider does not support multiple asynchronous tool calls for the same session #686

Activity

1. chemicL

   added

   bugSomething isn't workingSomething isn't working

   P2Moderate issues affecting some users, edge cases, potentially valuable featureModerate issues affecting some users, edge cases, potentially valuable feature

   on Feb 20, 2026
2. chemicL

   added the

   Bug

   issue type on Feb 20, 2026
3. dominikozi

   added a commit that references this issue on Feb 24, 2026

   fix: handle concurrent sendMessage calls in StdioServerTransportProvi…

   ...

   48e855d
4. marekpompura commented on Aug 30, 2026

   

   marekpompura

   on Aug 30, 2026

   More actions

   Independently reproduced and root-caused this exact bug (same stack trace, StdioMcpSessionTransport.lambda$sendMessage$0 → "Failed to enqueue message") while building an MCP server, still present as of the latest release (mcp-core:2.0.1) - confirmed by diffing 2.0.0 and 2.0.1's published sources, StdioServerTransportProvider's outbound sink handling is byte-for-byte unchanged between them (2.0.1 only adds an unrelated inbound-message max-size guard).

   Root cause

   StdioMcpSessionTransport.outboundSink is a single Sinks.many().unicast().onBackpressureBuffer() shared by the whole session:

   this.outboundSink = Sinks.many().unicast().onBackpressureBuffer();
   // ...
   public Mono<Void> sendMessage(McpSchema.JSONRPCMessage message) {
       return Mono.zip(inboundReady.asMono(), outboundReady.asMono()).then(Mono.defer(() -> {
           if (outboundSink.tryEmitNext(message).isSuccess()) {
               return Mono.empty();
           } else {
               return Mono.error(new RuntimeException("Failed to enqueue message"));
           }
       }));
   }

   unicast() sinks are documented as safe for exactly one producer thread at a time. sendMessage() gets called from whatever thread each tool call's completion lands on - concretely, this project's own server-side reproduction found two calls to the same tool completing close enough in time to trigger the race reliably (~100% reproduction across explainQuery, listSchemas, getCapabilities in different testing), and confirmed the race persists even under a global lock serializing tool execution - the actual concurrent tryEmitNext call happens in an async continuation downstream of the tool callback returning, a thread hop application code has no hook into. This matches #875's independent analysis of the client-side StdioClientTransport hitting the identical unicast()-sink misuse pattern (their repro traced it to SinkManySerialized's CAS guard specifically) - same class of bug, both sides of the stdio transport.

   I see #834 already proposes a fix in this same file (emitNext() + Sinks.EmitFailureHandler.busyLooping(Duration.ofSeconds(1)) instead of tryEmitNext()) and was reviewed same-day by @chemicL - looks like it's been stalled since, with merge conflicts now. If it's still on the table, one thing worth weighing against a plain synchronized write (below): busyLooping retries by spinning with a timeout, so it still has a (very unlikely in practice, but non-zero) failure mode under sustained contention that a blocking lock doesn't - a thread waiting on a lock simply waits, with no cap. Not meant as a knock on that PR, just additional data point in case it helps get it unstuck.

   A workaround that closes it completely, if useful to anyone hitting this before an official fix lands

   Since McpServerTransportProvider/McpServerTransport are public interfaces (StdioServerTransportProvider itself is not extensible - StdioMcpSessionTransport is a private inner class), a drop-in replacement transport provider that performs the outbound write directly and synchronously under a plain lock - instead of through a Reactor sink at all - eliminates the race entirely, since there's no unsynchronized enqueue step left to fail:

   public Mono<Void> sendMessage(McpSchema.JSONRPCMessage message) {
       return Mono.fromRunnable(() -> writeMessage(message));
   }
   
   private void writeMessage(McpSchema.JSONRPCMessage message) {
       if (isClosing.get()) return;
       String json = jsonMapper.writeValueAsString(message)
               .replace("\r\n", "\\n").replace("\n", "\\n").replace("\r", "\\n");
       synchronized (writeLock) {
           outputStream.write(json.getBytes(StandardCharsets.UTF_8));
           outputStream.write('\n');
           outputStream.flush();
       }
   }

   (Inbound processing - a dedicated reader thread deserializing newline-delimited JSON-RPC and dispatching to session.handle(...) - can mirror the SDK's own approach unchanged; that side was never the problem.)

   Verified this approach against a real server: 21/21 concurrent-call runs across three different tools with zero dropped responses, where the stock StdioServerTransportProvider dropped a response in the large majority of runs for the same reproduction. Happy to share the full class if it'd help toward an official fix.
5. chemicL commented on Sep 4, 2026

   

   chemicL

   on Sep 4, 2026

   Member

   More actions

   The issue is resolved via #935. The design with asynchronous signatures makes the solution based on synchronized blocks in direct writes in unfeasible as it could block on NIO threads in same rare cases. The Sink in the middle decouples the single consumer from multiple producers assuring that writing happens on a single thread in a serialized fashion.
6. chemicL

   closed this as completedon Sep 4, 2026