Frun1na opened a new issue, #6098: URL: https://github.com/apache/rocketmq-dashboard/issues/6098
### 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 a unit test against that commit (the affected code is the web client) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web client's list rendering browser: not applicable — reproduced in a jsdom unit test (vitest + Testing Library) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with stubbed DLQ endpoints in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug The repository has a documented clamp for server-paginated lists: when a page query answers with no rows but a non-zero total and the page is past the first one, re-query the last valid page instead of rendering a permanently empty table (`web/src/pages/ops/alerts.tsx:372-381` calls it deliberate policy, and eight pages implement it). Both paginated dead-letter lists in `web/src/pages/instance/dlq.tsx` are missing it: - the group list (`listDLQGroups`, `:187`) stores `result.items` / `result.total` unconditionally. Dead-letter groups shrink under the user — resending drains them and the server reaps empty ones — so a user on the last page gets an empty table with the old total and no way to recover except editing the search box. - the message drawer (`listDLQMessages`, `:391`) has the same gap with a trigger inside the page: resending every message of the current page empties it, and the reload after the resend keeps the drawer on that page. Its own silences/selection handling shows the shrink is expected: the group loader just below the missing clamp prunes the selection against the freshly loaded groups. ### Steps to Reproduce Reproduced by unit tests rather than against a cluster; the endpoint stubs are the only setup needed: 1. Render `DlqPage` with `listDLQGroups` answering `{ items: [one group], total: 40 }` for page 1 and `{ items: [], total: 20 }` for page 2 (equivalently: page to 2 and let the groups drain). 2. Click page 2 of the group table: no clamp request is fired, the table renders empty while the pager still offers page 2. 3. For the drawer: open a group's messages, page to 2, and resend them; the drawer reloads page 2 and stays empty. ### What Did You Expect to See? The same clamp the other paginated lists use: re-query the final page so the list recovers on its own. ### What Did You See Instead? A permanently empty group table (or message drawer) with the stale total, until the user changes the search or the page manually. ### Additional Context - A fix with one regression test per list follows in a pull request. - Both are pinned by unit tests that fail on `5e4c39b0` and pass with the fix. ### 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]
