unbridled-41 opened a new pull request, #4322:
URL: https://github.com/apache/rocketmq-dashboard/pull/4322
Fixes #4168 (resubmission of #4169 per @lizhimins's review).
## Problem / Evidence
On the Producer page, `handleTopicChange`
(`web/src/pages/studio/Producer.tsx`) only resets the producer-group
suggestions, so after switching the selected topic the connection table and
readiness banner keep showing the previous topic's results. It also never
invalidates a pending query, so the exact race the state reset targets is left
open: a slow in-flight response repopulates what a scope change just cleared.
## Root cause / Fix
Per the review on #4169: clearing visible state without bumping
`queryRequestIdRef` / clearing `queryInFlightRef` (as `handleInstanceChange`
does) does not hold under the race.
This PR extracts one shared `resetConnectionQuery` helper that
- bumps `queryRequestIdRef.current` so the pending response's `requestId`
guard fails,
- clears `queryInFlightRef.current` so a fresh query is not blocked,
- resets `connectionList`, `connectionSummary`, and `loading`.
`handleInstanceChange` now uses the helper (replacing its inline ref
bumps/clears — behavior unchanged), and `handleTopicChange` uses it too, so a
topic change invalidates the in-flight query and drops the previous topic's
visible results exactly like an instance change does. The export button's
existing `disabled={connectionList.length === 0}` guard keeps stale rows from
being exported until a new query runs.
## Tests
One real race regression replaces the previous PR's export test (dropped as
requested — its mock omitted `topic`/`producerGroup`, which the server always
populates, so the export fallback it asserted is unreachable in production):
- `discards a slow connection response after the topic changes`: submit a
query for topic A whose response is held pending, switch the topic to B while
it is in flight, then resolve A's response — the stale row and readiness banner
must not appear, and a fresh query for B must run (proving the in-flight slot
was released).
- Red on unmodified base `25132a0d` (fix stashed): `FAIL … expected document
not to contain element, found <span>生产者连接健康</span>` — the resolved stale
response was written back after the switch.
- Green after the fix: `npx vitest run
src/pages/studio/__tests__/Producer.test.tsx` → `Test Files 1 passed (1)`,
`Tests 14 passed (14)` (13 pre-existing + 1 new).
- Full web suite: two runs → `3 failed | 117 passed` and `2 failed | 118
passed`; the failing set differs per run
(`BrokerCluster`/`ConsumerPage`/`NotificationDeliveriesPage`/`MetricsExplorer`),
and every one of those files passes in isolation (`BrokerCluster` 15 passed,
`ConsumerPage`+`NotificationDeliveriesPage`+`MetricsExplorer` 59+25 passed) —
the documented full-suite parallel-load flakiness, none touched by this change.
- `eslint` clean on both changed files (also enforced by the pre-commit
`lint-staged` hook), `tsc --noEmit` clean, `vite build` succeeds (`✓ built in
8.63s`).
## Risk
Low. The helper is the existing `handleInstanceChange` invalidation sequence
moved into a shared function; `handleTopicChange` additionally gains the same
invalidation. Users who relied on switching topics while keeping the old table
on screen now see an empty table (export disabled) until they run a new query —
the same behavior an instance switch already produces.
--
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]
