Frun1na opened a new issue, #6132: URL: https://github.com/apache/rocketmq-dashboard/issues/6132
### 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, or I have stated the exact version I am running below. ### Studio Version branch: rocketmq-studio git commit id: 5e4c39b0 deployed as: reproduced by unit tests against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the Aliyun topic mapping and in the console rendering, not in persistence browser (for UI issues): not applicable — reproduced with jsdom in a vitest run ### Connected RocketMQ Cluster RocketMQ version: Alibaba Cloud RocketMQ 5.x via the OpenAPI SDK (`alibabacloud-rocketmq20220801` 5.0.8) access mode: cloud instance through a stored credential deployment: not applicable — reproduced with the SDK response models in a unit test ### Describe the Bug Every topic of an Aliyun instance is presented as a topic **without queues**. `AliyunConverters.toTopicVO` (`AliyunConverters.java:119-131`) sets `writeQueues` and `readQueues` to 0 because the SDK's `ListTopicsResponseBody.List` carries only `createTime`, `instanceId`, `messageType`, `regionId`, `remark`, `status`, `topicName` and `updateTime` — no queue counts at all. The zeros then travel as if they were measurements: - the topic detail drawer renders 写队列数 0 / 读队列数 0; - the topic CSV export prints `0` for both columns; - the topic comparison (`compareTopicInventories`) treats them as real values, so comparing a cloud instance against any other instance reports `writeQueues: 8 -> 0` drift for **every** topic, and the Drift column is unusable; - the rebuild/sync actions read the counts from the list row and send the placeholders back to the broker. `CreateTopicRequest` has no queue field either (`instanceId`, `liteTopicExpiration`, `maxSendTps`, `messageType`, `pop`, `remark`, `topicName`), and `AliyunInstanceProvider.createTopic` therefore ignores the counts the console asks for — so the placeholder cannot be replaced by a real value on this vendor. ### Steps to Reproduce 1. Run the converter case added in the pull request below at `5e4c39b0`: `cd server && mvn -B -ntp test -Dtest=AliyunConvertersTest#toTopicVoShouldMarkTheQueueCountsItCannotReadUnavailableTest` 2. Or, against a live Aliyun instance: `GET /api/topics/page?instanceId=<aliyun>` returns `writeQueues: 0, readQueues: 0` for every topic, and the topic comparison against an Apache instance labels all of them as drifted. ### What Did You Expect to See? The console should say that the vendor does not report queue counts, the way the same provider already marks the lag and TPS it cannot read (`AliyunConverters.toTopicConsumerVO` sets `metricsAvailable(false)` for exactly this reason), instead of presenting 0 as the queue count. ### What Did You See Instead? `0` write queues and `0` read queues on every Aliyun topic in the detail drawer and in both CSV exports, false `writeQueues` / `readQueues` drift rows in the comparison, and no signal anywhere that the numbers were never measured. ### Additional Context A fix with regression tests follows in a pull request. ### 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
