Frun1na opened a new pull request, #4637:
URL: https://github.com/apache/rocketmq-dashboard/pull/4637
## Which Issue(s) This PR Fixes
Fixes #<to-be-filled>
## Brief Description
The `rmqctl mcp stdio` proxy could not carry the server-initiated half of
the MCP protocol:
1. **Server→client requests were auto-rejected.** The proxy only registered
`SetNotificationHandler` on its Streamable HTTP transport. When the upstream
server sent a request over the SSE stream (`sampling/createMessage`,
`roots/list`, `elicitation/create`, ...), mcp-go answered it with `-32601
method not found` because no request handler existed. The session now registers
`SetRequestHandler`: the request is serialized to the stdio client, and the
handler waits for the matching response frame (respecting the handler context
and session shutdown) so mcp-go POSTs it back upstream.
2. **Client responses were rejected and answered with a fake error.**
`decodeMCPMessage` only accepted frames with a `method`, so a response frame
(`{id, result}` / `{id, error}`) produced by the stdio client failed with
"missing method", and `SendMessage` wrote a synthetic `-32603` error frame to
the upstream stream. Response frames are now decoded (`mcpClientResponse`) and
routed to the pending forwarded request by id; responses with no pending
request are dropped with a warning, since the forwarding handler has already
timed out at that point.
The pending-response channel is registered before the request becomes
visible to the client, so the response frame can never win a race against
registration. The `mcpSession` interface and the proxy loop in `cmd/` need no
changes.
## How Did You Test This Change?
```
$ cd rmqctl && go test ./... # all packages ok
$ go test -race -count=20 ./internal/studio/ # stable across 20 runs
$ go vet ./... && gofmt -l . # clean (no output)
$ make catalog-verify # ok
```
New tests:
- `TestSessionForwardsServerRequestsAndClientResponses` — a fake upstream
SSE stream delivers `sampling/createMessage`, the test asserts the request is
written to the stdio side, then the client's `{id, result}` frame is relayed
back and observed on the upstream POST.
- `TestDecodeMCPMessageAcceptsClientResponseFrames` — `{id, result}` and
`{id, error}` frames decode as responses instead of failing with "missing
method".
## Checklist
- [x] Followed the style guide and code conventions
- [x] Added tests that prove the fix (bidirectional forwarding covered)
- [x] No new warnings from `go vet` / `gofmt`
--
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]
