unbridled-41 opened a new pull request, #4169:
URL: https://github.com/apache/rocketmq-dashboard/pull/4169
Fixes #4168.
## Problem / Evidence
On the Producer page (Studio), switching the selected topic only resets the
producer-group suggestions (`handleTopicChange`,
`web/src/pages/studio/Producer.tsx`, lines 162-166 on base `0a596661`), while
the connection table and readiness banner keep showing the previous topic's
results. `handleInstanceChange` (lines 121-131) already clears
`connectionList`/`connectionSummary` for instance switches; the topic dimension
was missed. `handleExport` (lines 277-294) stamps rows with `topic:
connection.topic ?? selectedTopic` (line 286), so exporting from that state
relabels topic A's client connections as topic B.
Two regression tests fail on the unmodified base:
1. `clears stale connection results when the topic changes` → `expected
document not to contain element, found <td ...>producer-1</td>` — the stale
client row survives a topic switch.
2. `exports connections with the form topic after switching topics` → the
export button stays enabled with cached stale rows, so an export would stamp
them with the newly selected topic.
## Root cause / Fix
Root cause: `handleTopicChange` resets only the group suggestions, not the
previous query's visible results.
Fix: clear `connectionList` and `connectionSummary` in `handleTopicChange`,
matching `handleInstanceChange`. The export button's existing
`disabled={connectionList.length === 0}` then prevents exporting until a fresh
query is run.
## Priority & scoring
- Impact 28/40 (wrong client inventory presented and exported under the
wrong topic — misleading diagnostics on the producer page) + breadth 13/20
(single page, but the table/export/banner are its core outputs) +
reproducibility 20/20 (deterministic UI regression) + maintainability value
12/20 (completes the state-reset symmetry the file already maintains for
instance changes) = **PRIORITY 73** ≥ 70.
- Two-line state reset mirroring an in-file pattern, with red→green
regressions → **FIX_CONFIDENCE 92** ≥ 80.
## Tests
- Red: `npx vitest run src/pages/studio/__tests__/Producer.test.tsx` on base
with only the tests added → `Tests 2 failed | 13 passed (15)` (both new
regressions above).
- Green: same command after the fix → `Test Files 1 passed (1)`, `Tests 15
passed (15)`.
- Full web suite after the fix: `npx vitest run` → `Test Files 3 failed |
112 passed (115)`, `Tests 3 failed | 943 passed (946)` — the failing files are
`ClusterPage` ×1, `ConsumerPage` ×1, `NotificationDeliveriesPage` ×1, none of
which this change touches; running those three files in isolation with the fix
applied → `Tests 59 passed (59)`, consistent with the documented load-flakiness
under full-suite parallelism (see verification comment for the base stash
comparison).
- `npm run build` → `✓ built in 11.08s`; `eslint` clean on both changed
files (after fixing one unused-var warning introduced by the new test); `tsc
--noEmit` clean.
## Risk
Low. Two state resets added to an existing change handler; no API, data, or
visual changes beyond the intended clearing. Users who relied on switching the
topic while keeping the old table on screen now see an empty table (with the
export button 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]
