tju-yxq opened a new issue, #6158:
URL: https://github.com/apache/rocketmq-dashboard/issues/6158
> Resubmission of #5413 — the original report was closed by the repo's 7-day
stale bot for inactivity, not because it was fixed or rejected; the problem is
still reproducible on the current `rocketmq-studio` head. An updated PR
carrying the fix is being filed against this report.
## Problem
When a type-filter or search change on the instance page triggers a reload
that **fails**, the table keeps listing the rows fetched for the **previous**
query under the new filter. The request-id machinery correctly prevents a
racing response from repopulating old data — but the failure path of the latest
request simply never clears what was already on screen. A filter switch to
Direct 模式 whose load fails silently keeps showing PROXY_CLUSTER rows under the
Direct-only filter, and once the transient error toast auto-dismisses there is
nothing indicating the listed data belongs to the old query.
## What did you do (steps to reproduce)?
1. Open **实例管理** with instances of mixed types; all are listed.
2. Switch the type filter to Direct 模式 and have the reload fail (backend
briefly unavailable).
3. The error toast appears and disappears; the table still lists every
instance from the unfiltered view — including non-Direct rows — under the
Direct filter.
## 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 only a transient toast as a
clue.
## Root cause
`web/src/pages/instance/index.tsx`, `loadInstances` (lines 155-176):
```tsx
} catch {
if (requestId === requestIdRef.current) {
message.error(t('instance.listLoadFailed')); // toast only —
`instances` keeps the old rows
}
}
```
The sibling pages handle the identical failure explicitly:
`BrokerCluster.tsx` (lines 218-221) calls `clearData()` in its catch so a
failed scope load never leaves the previous scope's rows on screen, and
`AlertRuleAssetList` sets a persistent `loadError` with a retry. The instance
page's catch was left with the toast alone.
## Expected behavior
- When the latest load fails, the rows and the selection are cleared
(selection follows the rows, so no batch action can target rows that are no
longer on screen) alongside the existing toast.
- Racing responses remain guarded by the request ids (unchanged).
- Successful loads are unchanged.
## Acceptance criteria
- [ ] Regression proof: on the current code, a failed reload after a filter
change keeps the old rows listed; with the fix they are cleared.
- [ ] The error toast still appears for the latest failed request.
- [ ] Stale-response guarding (an older response finishing after a newer
request) is unchanged and still tested.
- [ ] Every other instance-page behavior (create/update/import/delete, batch
selection) is unchanged.
## Environment
Branch `rocketmq-studio` at `6a68042f`; file:
`web/src/pages/instance/index.tsx`.
## Duplicate check
Searched open and closed issues for `instance list failed`: no item covers
the stale-rows-on-failed-reload behavior. The open Loyal-Young issues
#5369/#5379 are the same genre on different pages (data source filter, audit
filter); this page's variant is unclaimed.
--
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]
