zhang-arvin opened a new pull request, #7046: URL: https://github.com/apache/shenyu/pull/7046
Fixes #7041 ## Problem `StreamableHttpSessionTransport` captured MCP framework responses in a single `lastSentMessage` slot guarded by `responseReady`. When multiple `tools/call` requests are processed concurrently on the same session, the response of request A can be overwritten by the response of request B, and A's `resetCapturedMessage()` can then wipe out the response B just wrote. This yields cross-delivered responses, empty responses, or responses with the wrong JSON-RPC id. ## Fix - Add a `ConcurrentHashMap<String, JSONRPCMessage> messageResponses` keyed by the JSON-RPC response id to allow per-message correlation. - In `sendMessage`, keep the existing `lastSentMessage`/`responseReady` behaviour (needed by the initialization handshake) and additionally store `JSONRPCResponse` messages in `messageResponses` keyed by `resp.id()`. - Add `getLastSentMessage(Object messageId)` which looks up the correlated response when a message id is available and falls back to `lastSentMessage` otherwise; the no-arg `getLastSentMessage()` and `isResponseReady()` are kept for existing callers. - `waitForTransportResponse` now first tries the id-correlated response and returns it with HTTP 200; when no correlated response exists it keeps the previous fallback (`lastSentMessage` and the synthetic success response). - `processWithExistingSession` clears only the response captured for the current message id via the new `resetCapturedMessage(Object messageId)` overload, without disturbing the handshake-related single slot. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
