unbridled-41 opened a new pull request, #4245:
URL: https://github.com/apache/rocketmq-dashboard/pull/4245
Fixes #4244.
## Problem / Evidence
Creating a consumer group — through the single create dialog or the CSV
import — updates the group list only locally: `setGroups((prev) => [created,
...prev.filter(...)])` prepends the created group to the currently loaded rows
without refetching the server-paginated list and without updating the
pagination total.
The list is server-paginated (`loadConsumerGroupPage(page, pageSize)`
fetches `listConsumerGroupPage({page, pageSize})` and sets both rows and
`totalGroups`), and `autoRefresh` defaults to `false`, so the divergence
persists until a manual refresh:
- the pagination footer keeps showing the pre-create total (`共 N 个 Group`
with the stale N);
- on a full page the prepended row pushes the page's last row out of view;
- with the user on page > 1, the new group is injected into that page even
though the server's ordering places it elsewhere.
The same file already refetches the page after single and batch delete — the
create/import paths were the only list mutations that skipped the reload. This
is the same defect class maintainers already fixed for the topic inventory
(merged #3339) and that #3306 tracks for ACL users.
## Root cause / Fix
The create and import paths mutated the local array instead of reloading the
paginated inventory. Fix (mirroring #3339's pattern on the topic page):
1. `reloadConsumerGroupPageAfterDelete` is renamed to the neutral
`reloadConsumerGroupPage` (both existing delete call sites updated).
2. The single-create flow replaces its local prepend with `await
reloadConsumerGroupPage()`.
3. The CSV import flow replaces its `setGroups` prepend with `await
reloadConsumerGroupPage()` when at least one group was created.
## Priority & scoring
PRIORITY 76 = impact 28 (post-write inventory divergence: stale total,
evicted rows, misplaced new group on an inventory operators rely on right after
creating) + blast radius 12 (both list-mutating flows of the consumer group
page) + reproducibility 20 (deterministic: create a group with default settings
and read the footer) + maintenance value 16 (adopts the exact reload pattern
maintainers merged for topics and this page already uses for deletes).
FIX_CONFIDENCE 92: mechanical reuse of the in-file reload callback; the new
regression test fails red before and passes green after, and the delete/import
test suites pin the unchanged behavior.
## Tests
- New regression `reloads the paginated group list after creating a group`
(`web/src/pages/instance/__tests__/ConsumerPage.test.tsx`): creates a group,
asserts `listConsumerGroupPage` is re-fetched for the current page, the created
group renders where the server returns it, and the footer shows the refreshed
total. **Red before the fix** (`expected "vi.fn()" to be called 2 times, but
got 1 times` — no reload happened), **green after**.
- `npx vitest run src/pages/instance/__tests__/ConsumerPage.test.tsx` →
**32/32 passed** (31 pre-existing, including the delete-reload, batch-delete,
and CSV-import suites, unchanged).
- Full web suite `npx vitest run` on this branch: **982 passed (982) — zero
failures**, including the CSV-import test that exercises the reloaded import
path.
- `npx tsc --noEmit` clean; `npx eslint` on both changed files clean; `npm
run build` succeeds.
## Risk
Low. The only behavior change is that the list is re-read from the server
after a successful create/import instead of being patched locally; delete paths
are untouched. The import result modal (per-row success/failure state) is
driven by `importRows`, not by the group list, so partial-failure reporting is
unaffected.
--
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]
