Frun1na opened a new issue, #6079: URL: https://github.com/apache/rocketmq-dashboard/issues/6079
### 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 with a stubbed Aliyun client in a unit test against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the Aliyun provider's paging loops browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — the defect is reproduced with a stubbed Aliyun Cloud SDK client access mode: not applicable deployment: ApsaraMQ for RocketMQ 5.x (Aliyun), exercised through `AliyunClientFactory` stubs ### Describe the Bug `AliyunInstanceProvider.listTopics` and `listConsumerGroups` page `ListTopics` / `ListConsumerGroups` and end the loop on a page shorter than the requested `PAGE_SIZE`, without consulting the `TotalCount` the same response carries: - `AliyunInstanceProvider.java:173` and `:336` — `if (hasFetchedAll(page, AliyunConverters.PAGE_SIZE, data.getTotalCount()) || list.size() < AliyunConverters.PAGE_SIZE) break;` the short-page test is evaluated second but `hasFetchedAll` compares the rows *requested* (`page * PAGE_SIZE`) with `TotalCount`, not the rows the response actually carried. - `AliyunInstanceProvider.java:230` — `hasFetchedAll` is `(long) page * pageSize >= totalCount`, so with `TotalCount = 321` and a 20-row page 1 the helper is false (100 < 321) and the short-page term ends the scan anyway, returning 20 of 321 rows. A short page that still leaves `offset + returned` below a known non-negative `TotalCount` therefore produces a truncated topic or consumer group inventory that Studio renders as complete. The same defect was fixed for the Tencent provider in #4531 (`34b03320`, `fix(tencent): reject incomplete resource pages`), which added `requireCompletePage` and changed `hasFetchedAll` to count returned rows; the Aliyun provider was never brought to that shape. ### Steps to Reproduce The defect is pinned by unit tests; no live cloud account is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=AliyunInstanceProviderTest ``` `listTopicsShouldRejectIncompletePageWhenTotalCountRequiresMoreTest` and `listConsumerGroupsShouldRejectIncompletePageWhenTotalCountRequiresMoreTest` stub one page containing a single row while the same response reports `TotalCount = 2`, and assert the provider rejects the contradictory page instead of returning it. Before the fix both return the single row and fail with `Expecting code to raise a throwable.` ### What Did You Expect to See? A short page that contradicts a non-negative `TotalCount` should be rejected the way the Tencent scans already do it (502, "Aliyun returned an incomplete page"). A missing or negative `TotalCount` and a genuinely empty page must keep ending the scan, so an empty catalog still resolves to an empty list. ### What Did You See Instead? `listTopics`/`listConsumerGroups` return the short page as the complete inventory, so the topic list and the consumer group list show fewer resources than the provider reported, with no signal that the scan stopped early. ### Additional Context A fix with regression tests follows in 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]
