tju-yxq opened a new issue, #5494:
URL: https://github.com/apache/rocketmq-dashboard/issues/5494
## Problem
On ten pages, a failed list reload after a filter, search, scope, or
pagination change left the **previous query's rows listed under the new
filter**. The failure feedback differed — eight pages showed only a transient
toast, two showed a persistent error banner — but in both cases the table kept
rendering rows that did not match the active filter. Once the toast
auto-dismissed there was nothing indicating the data belonged to the old query.
The instance page already handles this correctly (clearing rows and
selection in its catch). Ten other pages were missing the same discipline.
## What did you do (steps to reproduce)?
For any of the affected pages:
1. Load the list with data (e.g., consumer groups for an instance).
2. Change a filter, search term, or page — and have the reload fail (backend
briefly unavailable).
3. The error toast appears and disappears; the table still lists rows from
the **old** query under the **new** filter.
Concretely per page: consumer groups (old instance's groups under a new
search), topic list (stale topics under a new type filter — the client-side
mask doesn't cover type changes), audit feed (old records under new filters),
notification deliveries (old feed under a new channel), system alerts (old
alerts under a new level), alert rules (old rules and their selection under a
new search), data sources, cloud credentials, DLQ groups and its detail modal,
and message query results.
## What did you expect to see?
A failed reload of the current query does not leave the previous query's
rows on screen under the new filter.
## What did you see instead?
Stale rows contradicting the active filter, with no persistent indication
they belong to the old query.
## Root cause
Each page's load function wrote `setRows`/`setTotal` only in the success
path; the catch path only showed the error (toast or persistent banner) without
clearing what was already on screen. Examples — the consumer page's
`loadConsumerGroupPage` (around line 345):
```ts
} catch {
if (requestId === groupRequestIdRef.current)
message.error(t('consumer.fetchListFailed'));
return undefined;
}
```
and the DLQ groups effect (around line 201) sets `loadError` but keeps the
old `groups`:
```ts
.catch((error) => {
if (groupRequestIdRef.current === requestId) {
setLoadError(describeThrownMessage(error) || DEFAULT_LOAD_ERROR);
setLoading(false);
}
});
```
## Expected behavior
- When the latest load fails, the rows, the total, and (where present) the
selection are cleared alongside the existing error feedback.
- Racing responses remain guarded by the existing request-id / generation
checks (unchanged).
- Successful loads are unchanged.
## Acceptance criteria
- [ ] Regression proof: on the current code, a failed reload after a search
change keeps the old rows; with the fix they are cleared on every affected page.
- [ ] The total/pagination state is also cleared (the pager can no longer
highlight a page whose rows were never fetched).
- [ ] The existing stale-response guards (older response finishing after a
newer request) are unchanged and still tested.
- [ ] Every other page behavior (mutations, exports, detail drawers) is
unchanged.
## Environment
Branch `rocketmq-studio` at `6a68042f`; files: consumer.tsx, topic.tsx,
audit.tsx, notificationDeliveries.tsx, systemAlerts.tsx, alerts.tsx,
DataSourceTab.tsx, CloudCredentialTab.tsx, dlq.tsx (groups + detail),
message.tsx.
## Duplicate check
Searched open and closed issues for `failed reload`, `stale rows`, and
`filter change`: the open Loyal-Young issues #5369/#5379 cover the same genre
on different pages (data source filter, audit filter). The instance-page
variant was fixed by #5414; this extends the fix to the remaining ten pages in
one cohesive change per the grouping guideline #2107.
--
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]
