apache / apache/rocketmq-dashboard

Metrics Explorer profile panels freeze on their spinners when refresh also reruns the applied custom query

Open
#3,304 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1.4k
Forks
683
Avg merge
2d 14h
Merged PRs (30d)
58

Description

## Problem

Metrics Explorer (`web/src/components/MetricsExplorer.tsx`) uses one shared monotonic `requestId` ref for two independent flows: `loadAll` (profile panels) and `runCustomQuery` (custom query panel). Any action that triggers both synchronously makes the second flow bump the counter while the first is still in flight, so the first flow's results always fail their freshness guard (`currentRequest === requestId.current`) and are silently dropped:

- Clicking 刷新全部面板 with an applied custom query: the refresh handler calls `void loadAll(...)` and then `void runCustomQuery(...)`; `loadAll` captures N, `runCustomQuery` bumps to N+1 in the same tick. Every profile panel stays on its spinner forever (the panels were just set to `loading: true`), and the refresh button spins until a full page reload.
- Switching data sources while a custom query is applied (`activateDataSource` runs both).
- Running a custom query while the initial panel load is still in flight.

## Evidence / source

- Code inspection of the current `rocketmq-studio` branch (base commit 36126024): the refresh handler and `activateDataSource` both invoke `loadAll` and `runCustomQuery` back-to-back; `loadAll` bumps the shared counter at `MetricsExplorer.tsx:486`, `runCustomQuery` at `:560`, while the two flows write disjoint state slices (`panels` vs `customPanel`).
- Deterministic Vitest reproduction: `reloads profile panels when refresh also reruns the applied custom query` in `MetricsExplorer.test.tsx` fails on the unfixed source (the profile chart never re-renders after refresh) and passes with the fix.

## Impact

The monitoring view becomes unusable after a routine action: all metric panels freeze on spinners and require a page reload to recover.

## Expected behavior / acceptance criteria

- Profile panels and the custom query panel track their own request generations; each flow only invalidates its own in-flight results.
- The refresh action, data-source switches, and custom queries during a load all leave both flows able to publish their results.
- Regression coverage for the refresh-with-applied-custom-query freeze; it must fail on the unfixed code.

## Related work

- Existing range/profile superseding tests only cover loadAll-vs-loadAll; the cross-flow interaction is untested before the fix.

## PR

PR #3299 (includes the fix and the regression test).

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in web/src/components/MetricsExplorer.tsx, focusing on loadAll, runCustomQuery, and the refresh and data-source activation paths. Run the named Vitest regression in MetricsExplorer.test.tsx; done means profile and custom-query panels can both publish results after refreshes, data-source switches, and overlapping loads.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, testing-qa
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.