Frun1na opened a new issue, #4760: URL: https://github.com/apache/rocketmq-dashboard/issues/4760
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and found no similar issue. ### What Happened `rmqctl` silently corrupts int64 values beyond 2^53 that come back from Studio. The client decodes the response payload into the caller's `out any` (`internal/studio/client.go`), and `encoding/json` represents every JSON number inside an `any` as `float64`. Any value above `Number.MAX_SAFE_INTEGER` loses precision before it ever reaches the output layer: ``` server returns "msgOffset": 9007199254740993 rmqctl prints "msgOffset": 9007199254740992 (table, json and yaml output alike) ``` `types.DecodeMutationOutput` re-encodes the same decoded value to inspect it, so mutation summaries inherit the corrupted number as well. Nothing in `rmqctl` uses `json.Number` today. RocketMQ offsets and timestamps are the obvious int64-shaped fields; today they usually stay within 2^53, but the JSON contract is int64 and any larger value is silently wrong rather than reported. ### Expected Behavior Numeric literals from the Studio response survive the round trip unchanged, in every output format. ### Steps to Reproduce 1. Point `rmqctl` at a Studio endpoint whose payload contains an integer larger than 2^53 (a fake server returning `{"code":200,"data":{"items":[{"msgOffset":9007199254740993}]}}` works). 2. Run any passthrough command, e.g. `rmqctl broker list --instance-id i1 -o json`. 3. Observe `9007199254740992` in the output. ### Environment - RocketMQ Studio `rocketmq-studio` @ `7ce9a682` - `rmqctl` `internal/studio/client.go` (response decode), `internal/output` (render), `internal/types` (`DecodeMutationOutput` round trip) ### Are You Willing to Submit a Pull Request? Yes — #4759 fixes this. -- 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]
