pilichoumao opened a new issue, #6904:
URL: https://github.com/apache/rocketmq-dashboard/issues/6904
### Before creating this report
- [x] Searched existing issues and PRs. #6314/#6315 explicitly leave request
IDs and notifications unchanged; REST/YAML numeric output fixes cover another
boundary.
- [x] Reproduced on `rocketmq-studio` at
`a92c23144408cdf5729707050e9ecd9b75f1bad0`.
### Runtime environment
Linux x86_64, Go 1.27.1, current rmqctl dependency mcp-go v0.58.0. Tests use
a real local httptest HTTP endpoint with initialize/initialized handshake and
the production MCPClientSession. No live Studio/Broker, MySQL or browser is
required.
### Describe the bug
The SDK decodes JSON-RPC request IDs and notification `requestId` values
through float64. The rmqctl bridge consequently changes a valid large integer
identity before forwarding it, changes the returned ID, and can accept an
adjacent but different response ID because both decode to the same number.
Cancellation forwarding has the same identity problem.
### Steps to reproduce
Within the rmqctl module, decode and re-encode these typed SDK messages
(imports: `encoding/json`, `fmt`, and `github.com/mark3labs/mcp-go/mcp`):
```go
var request mcp.JSONRPCRequest
_ =
json.Unmarshal([]byte(`{"jsonrpc":"2.0","id":9007199254740993,"method":"tools/list"}`),
&request)
wire, _ := json.Marshal(request)
fmt.Println(string(wire))
var cancel mcp.JSONRPCNotification
_ =
json.Unmarshal([]byte(`{"jsonrpc":"2.0","method":"notifications/cancelled","params":{"requestId":9007199254740993}}`),
&cancel)
wire, _ = json.Marshal(cancel)
fmt.Println(string(wire))
```
Both numeric identities become 9007199254740992. The same behavior is
observable through the production session and an HTTP peer:
| Scenario | Current result |
| --- | --- |
| Request ID 9007199254740993 echoed by the peer | Sent/returned ID changes
to 9007199254740992 |
| Request ID 9223372036854775807 echoed by the peer | Sent/returned ID
changes to 9223372036854776000 on Linux amd64 |
| Request ID 9007199254740993, response ID 9007199254740992 | Mismatched
response incorrectly accepted |
| Cancel notification requestId 9007199254740993 | Forwarded as
9007199254740992 |
Small numeric IDs, string IDs, both numeric/string type-mismatch directions,
small cancellation IDs and string cancellation IDs are passing controls. The
four defect scenarios fail as regressions on unchanged production; all six
controls pass.
### Expected behavior
Preserve numeric request/cancellation identities and reject a response with
a different ID while retaining numeric-versus-string distinctions. This follows
the MCP response/cancellation correlation contract.
### Upstream dependency and integration scope
The upstream fix is already proposed by @mikamikasuki in
https://github.com/mark3labs/mcp-go/pull/1032 (currently open, head
b4832cd97a2e81cf1a4ddeb103d88bec38aa52e8). The latest release v1.3.0 still has
the float64 decoder, so updating to that release alone does not fix this issue.
As an isolated experiment only, applying that PR's client-relevant
`mcp/types.go` and `mcp/request_id_number.go` patch to a task-local SDK copy
makes all ten HTTP contract scenarios and the complete Studio client race suite
pass. This is evidence for the dependency root cause, not a claim that the
proposed SDK patch is merged, released, or fully validated as a RocketMQ
dependency upgrade. No SDK code is copied into a RocketMQ PR.
Proposed follow-up once an official fix is released:
- Evaluate the released SDK version and its API compatibility instead of
keeping a local fork.
- Add request/response identity, adjacent-mismatch and
cancellation-forwarding regressions at the Studio HTTP boundary; retain the
existing initialization/reconnect and parameter precision contracts, including
#6315.
- Run the full Go CI, catalog checks, platform builds and actual per-binary
license checks for the resulting dependency set.
### Willingness to contribute
I can contribute the RocketMQ integration and regression tests after the
upstream fix is available in a suitable official release. This issue tracks the
affected RocketMQ bridge and its integration criteria rather than duplicating
the SDK implementation.
--
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]
