Frun1na opened a new issue, #5648: URL: https://github.com/apache/rocketmq-dashboard/issues/5648
### 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 branch: `rocketmq-studio` git commit id: `6a68042f` deployed as: built from source ### Runtime Environment OS: Ubuntu 22.04 (WSL2) MySQL: not applicable — the defect is in the provider conversion, covered by the provider tests browser: not applicable (the web side renders whatever the server sends) ### Connected RocketMQ Cluster RocketMQ version: not applicable — the defect is in the tencent/aliyun provider adapters access mode: cloud provider adapters (Tencent DescribeMessage / Aliyun ListMessages) deployment: not applicable ### Describe the Bug Cloud instances show a fabricated `0 B` in the message Size field whenever the vendor API does not return a body size: - Tencent — `TencentInstanceProvider.toRecordVO` sets `.size(0)` for both the `DescribeMessage` and `MessageItem` paths, because neither carries a body size. - Aliyun — `AliyunConverters.toMessageRecord` sets `.size(data.getBodySize() == null ? 0 : data.getBodySize())`, so a ListMessages response without `BodySize` reports zero. The message page then renders that `0 B` as if it were a measurement, and a reader cannot tell "this message is empty" from "the vendor did not report a size". The Apache provider is unaffected: it reports the real `storeSize`. ### Steps to Reproduce 1. Open the message detail of any message on a Tencent instance (or an Aliyun message whose ListMessages entry has no `BodySize`). 2. Look at the 大小 / Size field: it reads `0 B` regardless of the actual message. 3. Server side, `TencentInstanceProviderTest#queryMessagesByMsgIdShouldReportUnknownSizeTest` pins the current value: on the unpatched provider the recorded size is `0`, not an unknown marker. ### What Did You Expect to See? An unknown size should not be presented as a number: the server should report an explicit unknown value (`-1`, as the same page already does for other unavailable fields) and the message page should render `-`, so a missing vendor value never reads as an empty message. ### What Did You See Instead? `size = 0` hardcoded by both cloud adapters, rendered as `0 B` in the table's Size column and in the detail panel. ### Additional Context - `MessageRecordVO.size` carries no "unknown" documentation today, so nothing stops a provider from fabricating a value. - the same applies to the DLQ/message-list paths that inherit this contract. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. --- Re-submission: the original report (#5081) was closed by the stale bot after 7 days without triage activity, and GitHub now rejects reopening items in this repository. Refiled unchanged; the fix PR is linked below. -- 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]
