Frun1na opened a new issue, #6544: URL: https://github.com/apache/rocketmq-dashboard/issues/6544
### 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 by unit tests against that commit (`AclPage.test.tsx`, `ConsumerPage.test.tsx`, `TopicPage.test.tsx`) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the console's pagination state, no database involved browser (for UI issues): not applicable — reproduced in jsdom through the existing page suites ### Connected RocketMQ Cluster RocketMQ version: not applicable — the page suites stub the list service, no cluster is contacted access mode: not applicable deployment: not applicable ### Describe the Bug Four list views stop clamping their page back when the list shrinks **to zero**, because the guard that does the clamping is gated on a non-zero total: - `web/src/pages/instance/acl.tsx:212` (ACL rules) and `:233` (ACL users) - `web/src/pages/instance/consumer.tsx:347` (consumer groups) - `web/src/pages/instance/topic.tsx:468` (topics) All four read ```ts if (items.length === 0 && total > 0 && page > 1) { setPage(Math.max(1, Math.ceil(total / pageSize))); } ``` `items.length === 0 && total === 0 && page > 1` is exactly the case the guard was written for - the page the operator is on no longer exists and the last valid page is 1 - but the `total > 0` term makes it fall through, so no follow-up query is issued and the view stays on the out-of-range page. `total === 0` also removes every page button but the first, so the page cannot be recovered by clicking; only changing a filter (which resets the page) gets the operator back. The two pages that already had this fixed, `settings/CloudCredentialTab.tsx:102-108` and `settings/DataSourceTab.tsx:158-165`, use the un-gated form and additionally only move the page when it is really beyond the last one: ```ts if (result.items.length === 0 && page > 1) { const lastPage = Math.max(1, Math.ceil(result.total / result.size)); if (page > lastPage) { setPage(lastPage); return; } } ``` With that shape the deleted-rows case still works, and the emptied-list case falls back to page 1. ### Steps to Reproduce Load page 2 of any of the three lists, and have it come back empty with `total = 0`: ``` cd web npx vitest run src/pages/instance/__tests__/AclPage.test.tsx -t 'out-of-range page is also the last one' npx vitest run src/pages/instance/__tests__/ConsumerPage.test.tsx -t 'out-of-range page is also the last one' npx vitest run src/pages/instance/__tests__/TopicPage.test.tsx -t 'out-of-range page is also the last one' ``` Each test drives the page to 2 with a 40-row first page and then has the list service answer `{ items: [], total: 0, page: 2 }`. Before the fix the three suites report `AssertionError: expected last "vi.fn()" call to have been called with [ ObjectContaining{…} ]`, because the last list call is still `page: 2`: the page never re-queried page 1. ### What Did You Expect to See? Once a load reports an empty page whose page number is beyond the last one the fresh total implies, the view goes back to page 1 and re-queries it - the behaviour the settings tabs already have. ### What Did You See Instead? The list stays on the out-of-range page, no page-1 query is issued, and because `total` is 0 the pager offers no other page to click. ### Additional Context A fix that drops the `total > 0` term in those four places, matching the settings tabs, follows in a pull request with one regression test per page. ### 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]
