Frun1na opened a new issue, #6517: URL: https://github.com/apache/rocketmq-dashboard/issues/6517
### 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: `779b8c0e` deployed as: reproduced with a stubbed Tencent `TrocketClient` in a unit test against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the Tencent message-query paging loop browser (for UI issues): not applicable ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed Trocket v20230308 client access mode: Tencent Cloud TDMQ RocketMQ 5.x OpenAPI (`DescribeMessageList`) deployment: Tencent Cloud managed instance, exercised through `TencentClientFactory` stubs ### Describe the Bug `TencentInstanceProvider.queryMessagesDetailed` (`server/.../provider/tencent/TencentInstanceProvider.java:662`) advances the paging offset by the number of records it has collected: - `request.setOffset((long) result.size())` at `:662`, where `result` only receives entries that passed the `if (item != null)` guard at `:672-676`. - The Tencent SDK returns `MessageItem[]`, and a JSON `null` array element becomes a `null` element in that array; the provider skips it, so a page of 100 rows that contains one absent entry contributes 99 records. - The next request therefore starts at offset 99 instead of 100, the API re-returns the row at index 99, and the returned list contains that message twice. The same collected count feeds `isLastPage(returned, total, result.size())` at `:685`, so the completion check is off by the same amount. The Aliyun sibling counts raw provider rows in its paging bookkeeping (`AliyunInstanceProvider.queryMessagesDetailed:543`), and this provider already guards against null array elements in three places (this loop, `toTopics`, `TencentAclService.listUsers`), so a page with an absent entry is an accepted shape rather than a malformed response. ### Steps to Reproduce The defect is pinned by a unit test; no live cloud account is needed: ``` cd server mvn -B -ntp test -DforkCount=1 -Dtest=TencentInstanceProviderTest ``` `queryMessagesShouldAdvanceByConsumedRowsWhenAPageSkipsAnAbsentEntryTest` stubs `DescribeMessageList` by offset: 150 rows in total, the first page returning the requested 100 rows with `items[50] = null`. It asserts that the second request starts at offset 100 and that the collected messages contain no duplicate msgId. Before the fix the second request starts at 99 and the assertion fails with `expected: 100L but was: 99L`. ### What Did You Expect to See? The next page offset (and the last-page check) should be derived from the rows the API has already returned, not from the records kept after filtering: a page of 100 rows advances the offset by 100 whether or not one of its entries was absent, so the query returns each message once. ### What Did You See Instead? With any absent entry in a page, the following page overlaps the previous one and the result list contains duplicate messages; a query whose total is reached exactly on such a page can also fetch one page more than needed. ### Additional Context A fix with a regression test 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]
