You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "Wang1rrr (via GitHub)" <gi...@apache.org> on 2026/09/22 05:38:35 UTC
[I] [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text [rocketmq-dashboard]
Wang1rrr opened a new issue, #4870:
URL: https://github.com/apache/rocketmq-dashboard/issues/4870
### 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 `rocketmq-studio` branch (the Studio trunk the pull request template points at), commit `4c697f07acde460e2344375cb1f82669f5b270fd`.
### Studio Version
```
branch: rocketmq-studio
git commit id: 4c697f07acde460e2344375cb1f82669f5b270fd
deployed as: built from source
```
### Runtime Environment
```
OS: Windows 11 (development box); the defect is in the web layer, so the host does not matter
MySQL: required only to run the console against a real cluster; reproduced from the sources and the web unit tests
browser (for UI issues): any; the affected page is web/src/pages/instance/message.tsx (消息查询 -> 详情)
```
### Connected RocketMQ Cluster
```
RocketMQ version: 5.5.0 self-managed (the Apache provider path); the Aliyun and Tencent providers set the same fields
access mode: Direct / Proxy Local / Proxy Cluster - the response shape is identical
deployment: any cluster holding a message whose body is larger than 64 KiB, or whose body is not valid UTF-8
```
### Build Toolchain
```
node: v22 (web/ package.json engines), npm ci from web/package-lock.json
```
### Describe the Bug
The server already tells the console when the body it is returning is not the whole body, and the console throws that information away.
`RocketMQMessageProvider.displayBody` (`provider/apache/RocketMQMessageProvider.java:881`-`:903`) caps what it puts on the wire:
- a body that decodes as UTF-8 is cut at `MAX_BODY_DISPLAY_BYTES = 64 * 1024` (`:87`), returned with `bodyEncoding = "UTF-8"` and `bodyTruncated = body.length > textLength`;
- a body that does not decode is base64-encoded, cut at `MAX_BINARY_BODY_DISPLAY_BYTES = 48 * 1024` (`:88`), and returned with `bodyEncoding = "BASE64"` and the same truncation flag.
`toRecordVO` (`:867`-`:869`) copies both onto `MessageRecordVO` (`instance/message/MessageRecordVO.java:39`-`:40`), the Aliyun provider sets them too (`provider/alibaba/AliyunConverters.java:241`, `:243`), and the AI tool schema publishes them (`resources/tool-catalog/tools/message.yaml:86`, `:88`).
The project's own API specification documents them. `docs/api-spec.md` §8.1 has a `#### MessageRecord` field table (`:1324`-`:1343`) listing `bodyEncoding` (`:1336`, 消息体编码，如 `UTF-8` / `BASE64`), `bodyTruncated` (`:1337`, 消息体是否被截断) and `propertiesTruncated` (`:1342`). So this is not an undocumented server behaviour that the frontend never learned about - the contract is written down, and the frontend type does not implement it.
The web type does not declare them. `web/src/api/message.ts:4`-`:19` lists `msgId`, `topic`, `tag`, `key`, `brokerName`, `queueId`, `queueOffset`, `body`, `storeTime`, `bornHost`, `storeHost`, `reconsumeTimes`, `properties`, `size` - no `bodyEncoding`, no `bodyTruncated`, no `propertiesTruncated`. So no page can read them, and `tsc` cannot complain about the omission because the fields are simply absent from the contract as far as the frontend knows.
The detail panel then presents whatever arrived as the message body:
- `web/src/pages/instance/message.tsx:959` renders `formatBody(selectedMsg.body)` inside a `copyable` `Paragraph` under the 消息体 heading, with no marker of any kind;
- `web/src/pages/instance/message.tsx:731` saves `formatBody(record.body)` as `${record.msgId}.json` with `type: 'application/json'`.
Two concrete operator-facing failures follow:
1. **A truncated body reads as a complete one.** Query a 5 MiB JSON message and the panel shows the first 64 KiB, pretty-printed, in a monospace block with a copy button, and the download writes a `.json` file. The JSON is cut mid-token, so anyone who copies or downloads it gets a file that does not parse, with nothing on screen explaining why. The natural conclusion - "this producer is writing malformed JSON" - is wrong.
2. **A binary body is shown as text.** For a protobuf, gzip or otherwise non-UTF-8 payload the panel shows base64 in a block styled for JSON, and the download names it `.json`. `formatBody` (`:140`) tries `JSON.parse` first, so the operator gets an unexplained wall of base64 rather than the statement "this is not text".
The repository already has the right idiom for exactly this situation on the DLQ page: `web/src/pages/instance/dlq.tsx:917`-`:923` renders 属性过多或单值过长，服务端已截断展示 whenever `propertiesTruncated` is set, and `DLQMessage` declares that field (`web/src/api/message.ts:123`). The message page is the one place the flags are dropped.
#4777 fixed the copy/download path to preserve the received body verbatim and explicitly scoped this out: "It does not recover backend-truncated or encoded data." This report is that remaining half - not recovering the data (the server never sent it) but stopping the UI from implying it did.
### Steps to Reproduce
1. Against a self-managed cluster, send a message whose body is larger than 64 KiB (a big JSON document is enough), and a second message whose body is binary (any non-UTF-8 bytes).
2. Console -> 消息查询, pick the topic, query by Message ID, and open 详情 on the large message.
3. Read the 消息体 block, then click 下载.
4. Repeat for the binary message.
### What Did You Expect to See?
The panel to state what the server already reported: that the body was cut at the display limit, so what is shown, copied and downloaded is incomplete; and, for the binary message, that the body is not UTF-8 text and is being shown base64-encoded. The same treatment the DLQ page gives `propertiesTruncated`.
### What Did You See Instead?
A complete-looking, pretty-printed body with no truncation marker, and a base64 blob presented as if it were the message text. Both download as `<msgId>.json` with `Content-Type: application/json`. The `bodyEncoding` and `bodyTruncated` values the server computed are present in the HTTP response and discarded by the frontend type.
### Additional Context
Fix scope: declare `bodyEncoding` and `bodyTruncated` on `MessageRecord`, render a truncation warning and a binary-body notice above the 消息体 block in the detail panel, add the two zh/en strings under `web/src/i18n/`, and pin both with tests in `web/src/pages/instance/__tests__/MessagePage.test.tsx` - one that fails if either notice disappears, one that fails if a complete UTF-8 body starts showing warnings.
Deliberately left out of this report, so the fix stays reviewable:
- the detail panel shows no message **properties** at all, so `propertiesTruncated` has nothing to annotate yet; adding a properties table (with the DLQ page's truncation note) is a separate change
- the download filename and MIME type for a base64 body (`.json` / `application/json`) - that is #4777's area
- `storeTime: number | string` on the same interface, which papers over the mock layer using ISO strings while `MessageRecordVO.storeTime` is a `long` and §8.1 documents the field as `number` (`:1338`)
### 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
Re: [I] [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins commented on issue #4870:
URL: https://github.com/apache/rocketmq-dashboard/issues/4870#issuecomment-5806560200
Fixed in 23d33f232 (#4872) on the `rocketmq-studio` branch.
Closing manually: GitHub only auto-closes an issue when the pull request is merged into the repository's default branch, and `rocketmq-studio` is not it.
--
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
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text [rocketmq-dashboard]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #4870:
URL: https://github.com/apache/rocketmq-dashboard/issues/4870#issuecomment-5771978728
**Issue Evaluation**
Category: `bug` | Status: **Confirmed**
The reported display issue is valid. When the message body is truncated by the server or encoded as BASE64, the detail panel renders it as if it were the complete plaintext body, misleading users.
**Root Cause:** No check for truncation flag or content encoding before rendering the body.
**Impact:** Users see incomplete or encoded message content without indication.
**Severity:** Low
An automated fix proposal may be generated. Reply `/approve` to proceed with PR generation.
---
*Automated evaluation by RockteMQ-AI*
--
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
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text [rocketmq-dashboard]
Posted by "Wang1rrr (via GitHub)" <gi...@apache.org>.
Wang1rrr commented on issue #4870:
URL: https://github.com/apache/rocketmq-dashboard/issues/4870#issuecomment-5771727422
Claiming this: https://github.com/apache/rocketmq-dashboard/pull/4872 is up against `rocketmq-studio` with the failing case pinned by a test and mutation-checked against the current behaviour
--
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
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins closed issue #4870: [Bug] the message detail panel prints a server-truncated or BASE64 body as if it were the whole text
URL: https://github.com/apache/rocketmq-dashboard/issues/4870
--
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
For queries about this service, please contact Infrastructure at:
users@infra.apache.org