Frun1na opened a new issue, #4638:
URL: https://github.com/apache/rocketmq-dashboard/issues/4638

   ### Bug Report
   
   **Describe the bug**
   
   While auditing `rmqctl mcp-stdio`, I found that the stdio-to-HTTP MCP proxy 
session cannot forward messages in either direction when they are not plain 
client-to-server requests. Two defects:
   
   1. **Server-initiated requests are auto-rejected.** When the MCP server 
sends a request over HTTP (e.g. `sampling/createMessage`, `roots/list`, or any 
custom server→client request), the proxy session has no request handler 
registered, so mcp-go answers it directly with `-32601 method not found` 
instead of forwarding it to the stdio client for an answer.
   
   2. **Client response frames are rejected.** When the stdio client sends back 
a JSON-RPC response (an object carrying `id` with either `result` or `error` 
but no `method`), the payload decoder only accepts request/notification shapes 
and reports a fake `-32603 Internal error`, so the response never reaches the 
HTTP server and the server-side call hangs until timeout.
   
   **To Reproduce**
   
   1. Run `rmqctl mcp-stdio --instance <id>` against an MCP server that issues 
server-initiated requests (or simply waits on a client response).
   2. From the MCP server side, send a request over the HTTP transport, or 
observe the stdio client answering an earlier request.
   3. The server receives `-32601 method not found` for its request (case 1) or 
the proxy errors with `-32603` and drops the client's response (case 2).
   
   **Expected behavior**
   
   The proxy should forward server-initiated requests to the stdio client, 
forward the client's JSON-RPC responses back to the HTTP server matched by 
request ID, and surface real transport errors instead of fabricated ones.
   
   **Additional context**
   
   Fix proposed in #4637.
   


-- 
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]

Reply via email to