unbridled-41 opened a new issue, #4842:
URL: https://github.com/apache/rocketmq-dashboard/issues/4842
### Studio Version
Branch `rocketmq-studio` (development trunk), commit `4c697f07`.
### Runtime Environment
Front-end only: `web/src/pages/ops/notificationDeliveries.tsx`. Any browser;
no backend dependency beyond the paginated deliveries endpoint.
### Describe the Bug
The notification-deliveries inventory is server-paginated, but its
pagination `onChange` always stores the page antd hands it, including when the
**size changer** fires:
```ts
onChange: (nextPage, nextPageSize) => {
setLoading(true);
setPage(nextPage); // stored even when the size changed
setPageSize(nextPageSize);
},
```
Reproducible sequence: 45 deliveries, pageSize 20, operator on page 3 →
switch the size changer to "50 / page":
1. antd fires `onChange(3, 50)`: the code requests page 3 at size 50.
2. Page 3 no longer exists (45 rows / 50 = 1 page). `total` updates to 45,
but `current: 3` stays past the last page.
3. The table renders **permanently empty** under a pager claiming page 3 of
1. Unlike the alerts-rule page (which clamps to the last valid page after a
shrunk total) and the audit page (whose `onChange` comment spells out this
exact scenario and resets the page on size change), this list has neither
protection — the only escape is changing a filter or manually clicking back.
The codebase already treats this as a defect pattern:
`web/src/pages/ops/audit.tsx` resets the page when `nextPageSize !== pageSize`
with the comment "A larger page size can make the current page exceed the new
total page count."
### Steps to Reproduce
1. Open **Ops > Notification Deliveries** with 45 deliveries (3 pages at
pageSize 20).
2. Navigate to page 3.
3. Change the page-size selector to 50 / page.
4. Observe an empty table with the pager on page 3 of a 1-page total.
### What Did You Expect to See?
Changing the page size lands on a valid page (page 1, following the audit
page's pattern), and the rows for the new size are displayed.
### What Did You See Instead?
The stale oversized page is requested; the table stays empty until the
operator intervenes.
### Additional Context
This is distinct from #3561 (bulk retry limited to the current page — a
feature-scope gap): here the defect is the pagination handler itself stranding
the table on a nonexistent page. Proposed fix in PR #4833, which adopts the
audit page's reset-on-size-change pattern and includes a regression test that
navigates to page 3 first (verified to fail against the unfixed handler, which
re-requests `{page: 3, pageSize: 50}`).
--
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]
