unbridled-41 opened a new pull request, #4189:
URL: https://github.com/apache/rocketmq-dashboard/pull/4189
{"body": "Fixes #4188.\n\n## Problem / Evidence\n\nOn the home dashboard,
the Metrics Explorer below the cluster cards stays mounted while the
\u5b9e\u4f8b selector changes (`dashboard.tsx:318` \u2014 `<MetricsExplorer
instanceId={selectedInstanceId} />`, no remount key). The profile-loading
effect re-runs on an instance change (its `loadAll` dependency closes over
`runQuery`, which depends on `instanceId`) and reloads every panel \u2014 but
it hardcoded `RANGE_OPTIONS[0]` (1h):\n\n- `MetricsExplorer.tsx` (before this
fix, line 539): `void loadAll(initialProfile, RANGE_OPTIONS[0]);` \u2014 inside
the effect that also runs on every instance change, not only on mount.\n-
`rangeId` state (line 415) and the Segmented control (line ~762) keep showing
the user's selection.\n\nRed test evidence (unfixed code, mocked
`queryMetrics`, `Date.now` pinned):\n\n```\n\u00d7 reuses the selected range
when the instance prop changes\nExpected (6h window): start 1799978400, step
'2m'\nReceived (1h d
efault): start 179996400, step '30s' \u2190 reload after instance-1 \u2192
instance-2\n```\n\nSo right after an instance switch, a user who selected 6h
sees one hour of data under a control labeled 6h.\n\n## Root cause / Fix\n\nThe
effect reused the initial-default `RANGE_OPTIONS[0]` on the reload path, where
a user selection already exists. Fix: keep the latest selected range in a ref
(`rangeIdRef`, kept in sync like the adjacent `dataSourceKeyRef`) and resolve
the reload's range from it; the 1h default still applies on the very first
mount before any selection. No request-guard behavior changes (the sibling
guards from PR #3299 are untouched).\n\n## Priority & scoring\n\nPRIORITY = 73
(\u5f71\u54cd 30: displayed range label and actual data window disagree after
every instance switch on the home dashboard for non-default ranges;
\u6ce2\u53ca\u8303\u56f4 13: the home dashboard explorer, all users switching
instances; \u53ef\u590d\u73b0\u6027 20: deterministic, captured in a compon
ent test; \u7ef4\u62a4\u4ef7\u503c 10: one-line semantic correction plus ref,
follows the established ref pattern in the same file). FIX_CONFIDENCE = 88
(deterministic red\u2192green test; same-file ref precedent; risk limited to
the reload path).\n\n## Tests\n\nRed (before the fix, same test,
`rocketmq-studio` @ 0a596661):\n\n```\nnpx vitest run
src/components/__tests__/MetricsExplorer.test.tsx -t \"reuses the selected
range\"\n \u00d7 reuses the selected range when the instance prop changes
724ms\n Expected: start 1799978400, step '2m' (6h window)\n Received:
start 179996400, step '30s' (1h default)\n```\n\nGreen (after the fix): `npx
vitest run src/components/__tests__/MetricsExplorer.test.tsx` \u2192 **21/21
passed**. The new regression test `reuses the selected range when the instance
prop changes` waits for the reload call to actually land
(`toHaveBeenCalledTimes(3)`) before asserting the window, so it is
deterministic (4 consecutive full-file runs + 1 shuffled run, all
21/21).\n\nFull web suite (`npx vitest run`): 945 tests, 944 passed, 1 failed
\u2014 `ConsumerPage > shows group health diagnostics from subscriptions,
progress and clients` (untouched file; isolated run with this change applied
passes 31/31; the same file is the recurring load-flaky file in this sandbox,
consistent with previous rounds).\n\n`tsc --noEmit` clean; `eslint` on both
changed files 0 errors/0 warnings; `npm run build` \u2713 (9.08s).\n\n##
Risk\n\nLow. The change only affects which range the reload uses; the initial
mount path is unchanged (ref holds '1h' before any selection). The ref-sync
effect follows the exact pattern of the adjacent `dataSourceKeyRef`.\n"}
--
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]
