[I] [Bug] Message details round numeric JSON payload values [rocketmq-dashboard]

["zmuxuny (via GitHub)" <gi...@apache.org>]

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

   ### Before Creating the Bug Report
   
   - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate.
   
   - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository.
   
   - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below.
   
   
   ### Studio Version
   
   rocketmq-studio at 127c47b06a268cc74224d5f34c56ec7c36ac0d55; unchanged production source.
   
   ### Runtime Environment
   
   Linux; React 18 / Ant Design 5; verified with the real MessagePage component in Vitest/jsdom. The same formatter runs in the browser. No live broker reproduction is claimed.
   
   ### Connected RocketMQ Cluster
   
   No cluster needed for the deterministic component regression. The message API fixture is an ordinary UTF-8 JSON body string, which matches RocketMQMessageProvider decoding.
   
   ### Build Toolchain
   
   Node.js 24.19.0, Vitest 4.1.10, existing package-lock dependencies.
   
   ### Describe the Bug
   
   The message-details body goes through JSON.parse followed by JSON.stringify in message.tsx (formatBody, lines 131-137; rendered at line 1087). This converts numeric tokens through JavaScript Number, changing valid payload values before the operator reads them. For example, an order ID 9007199254740993 appears as 9007199254740992. Int64 maximum and high-precision decimals are also altered.
   
   The API body remains a string. Copy/download already preserve it following #4777; the on-screen details still disagree with those original bytes.
   
   ### Steps to Reproduce
   
   1. Return a MessageRecord with bodyEncoding UTF-8 and body {"orderId":9007199254740993} from the existing message query.
   2. Query the topic and click the row Details button.
   3. Inspect the actual rendered body paragraph.
   4. Repeat with 9223372036854775807 and 0.1234567890123456789012345.
   
   Four added parameterized component cases were run on unchanged production with: node node_modules/vitest/vitest.mjs run src/pages/instance/__tests__/MessagePage.test.tsx --maxWorkers=1 -t TokenInDisplayedMessageBodyTest. Result: three failures at the rendered-text assertion and one passing safe-integer (42) control; 30 unrelated cases not selected. Duration 9.11 seconds.
   
   ### What Did You Expect to See?
   
   The displayed payload should retain its original numeric tokens. Pretty-printing may change insignificant whitespace, but should not replace an order ID or decimal value. Existing original-text copy/download behavior should stay intact.
   
   ### What Did You See Instead?
   
   Actual rendered values from the component regressions:
   - 9007199254740993 becomes 9007199254740992
   - 9223372036854775807 becomes 9223372036854776000
   - 0.1234567890123456789012345 becomes 0.12345678901234568
   - 42 remains 42 (control)
   
   ### Additional Context
   
   Related: merged #4777 / #4774 intentionally fixed copy/download only and explicitly left display policy or a lossless formatter for separate discussion. This report targets that remaining presentation path, not a duplicate export fix. Searches across open/closed PRs for formatBody, body display precision, lossless body, unsafe body and pretty printing found no competing display fix.
   
   Would maintainers prefer a whitespace-only formatter that preserves JSON tokens, or an original-text presentation mode? An unsafe-integer-only guard would miss decimal rounding. No new dependency or runtime parser change is proposed as settled design here. I can prepare focused regressions for the agreed policy, including nested JSON, escaped strings/Unicode, plain text, and existing copy/download coverage.
   
   AI assistance was used for source tracing and the reproduction tests.
   
   ### Are You Willing to Submit a Pull Request?
   
   - [x] Yes, I am willing to submit a pull request.


-- 
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: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org