Frun1na commented on issue #4758: URL: https://github.com/apache/rocketmq-dashboard/issues/4758#issuecomment-5760934832
PR #4637 (opened from #4638 before this write-up) already implements this full loop, so the design discussion has a working reference — it is green on `go test ./... -race`, vet, gofmt and catalog-verify, and would love a review. How it maps to the three points: 1. **Classify stdin frames before forwarding** — `decodeMCPMessage` (`rmqctl/internal/studio/mcp_message.go`) does exactly the three-way split: `method`+`id` → request, `method` without `id` → notification, `id` + `result`/`error` without `method` → response. The response case no longer fails with `missing method`. 2. **Response path back to the server** — #4637 takes a slightly different route than a dedicated `SendResponse` POST: when a server-initiated request is forwarded to the stdio client, the session registers it in `pendingRequests` by request id (`deliverResponse`, `mcp_message.go:331`), and the stdio client's answer is routed into that pending entry as a `JSONRPCResponse`. The mcp-go transport then carries it on the HTTP call it already owns for the in-flight server request, so its reconnect/error handling is reused instead of duplicated. A standalone `SendResponse` would work too; the pending-entry form just avoids a second write path racing the original call. 3. **Server-request handler → stdout** — `transport.SetRequestHandler(session.forwardRequest)` (`mcp_http.go:120`) writes the frame to stdout so the stdio client can answer it. Ordering and the existing concurrency limits are preserved, as in the proposal. If you would rather see the explicit `SendResponse` shape (or spot anything the pending-entry approach handles worse — e.g. a server request that outlives the stdio client), say so and I will adjust #4637 accordingly. -- 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]
