unbridled-41 opened a new pull request, #4658:
URL: https://github.com/apache/rocketmq-dashboard/pull/4658
Fixes #4654.
## Problem / Evidence
On `/ops/alerts`, bulk-deleting every rule on the current page steps the
pagination back one page even when the server still has enough rules to fill
that page:
- `web/src/pages/ops/alerts.tsx:615-618` (inside `handleBulkDelete`):
```tsx
if (rules.length === succeeded.size && page > 1) setPage((current) =>
current - 1);
else refreshRules();
```
- `rules.length === succeeded.size` means "the deleted rules filled the
current page", not "the current page is now empty". The single-row delete right
above (line 541) checks `rules.length === 1` — the actual row count of the page
— and `systemAlerts.tsx` silence deletion uses the same correct shape.
Reproduction: 41 rules, page size 20, go to page 2, select all 1 rows there,
bulk-delete. All succeed, 40 rules remain, page 2 is still valid — but the
condition holds and the page jumps back to page 1.
Red regression (new `stays on the page after a bulk delete clears a full
page while more pages remain`): after the bulk delete the list request is
expected for `page: 2`. On unmodified master it fails — the request was issued
with `page: 1`.
## Root cause / Fix
The bulk-delete branch treats "full page deleted" as "page now empty" and
unconditionally decrements the page. The client has no reliable emptiness
signal at this point (the refreshed total is only known after the reload), so
the correct minimal behavior is what the else-branch already does: refresh the
current page and let the refreshed `totalRules` drive the pagination display.
Fix: drop the page-decrement condition in `handleBulkDelete`; always
`refreshRules()` after a successful bulk delete.
## Priority & scoring
PRIORITY = 影响 24（导航位置静默丢失，操作员从第 3 页批量清理后被扔回第 2 页）+ 波及 10（CLUSTER 与 BUSINESS
两个告警域共用该组件）+ 可复现 20（确定性状态逻辑，无竞态）+ 维护价值 16（删掉一条语义错误的猜测逻辑）= **70**。FIX_CONFIDENCE
= **88**（删除误判分支，保留既有刷新路径；两个既有批量删除测试继续钉住其余行为）。
## Tests
- New regression: `AlertsPage.test.tsx#stays on the page after a bulk delete
clears a full page while more pages remain`.
- Red on master:
`expect(listAlertRulesPage).toHaveBeenLastCalledWith('CLUSTER',
expect.objectContaining({ page: 2 }))` failed — received `page: 1`.
- Green after the fix.
- Module: `npx vitest run src/pages/ops/__tests__/AlertsPage.test.tsx` →
`Tests 27 passed (27)` (26 pre-existing + 1 new).
- Full web suite (this branch): `npx vitest run --maxWorkers=4` → `Test
Files 122 passed (122)`, `Tests 1035 passed (1035)`, no failures (pristine
master on this machine: 1034 passing + 1 new test here = 1035).
- `npx tsc --noEmit` → clean. `npx eslint` on the two changed files → 0
errors (5 warnings verified as pre-existing by stashing the changes and
re-running eslint on the master versions).
- Frontend build: `npm run build` → `✓ built in 9.89s`.
## Risk
Low. The removed branch only ever fired when every rule on the current page
was deleted; that case now lands in the already-existing `refreshRules()` path.
A page that truly becomes empty still renders through the server response
(empty table + antd pagination clamps the visible page), and the single-row
delete path is untouched.
--
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]
