unbridled-41 opened a new issue, #4893:
URL: https://github.com/apache/rocketmq-dashboard/issues/4893
### Studio Version
branch: rocketmq-studio
git commit id: 1ef5d860799ac3fabfcdea942cc4dcc77ded7be6 (the revision the
reproduction below was verified against)
deployed as: built from source
### Runtime Environment
OS: Linux (WSL2). The reproduction is a component test rather than a live
deployment.
browser (for UI issues): display-independent; the regression test runs in
the Vitest jsdom environment.
### Connected RocketMQ Cluster
Not required for this reproduction. The defect is in the console's own state
handling and reproduces with the metrics service mocked, so no cluster or
Prometheus endpoint is involved.
### Describe the Bug
Switching the display language in the top bar while a custom PromQL query is
still running leaves the Metrics Explorer's custom panel on its spinner
permanently: the in-flight result is discarded and never replaced, so the chart
never appears. Because the panel keeps `loading: true`, antd also suppresses
clicks on the Run button, and the header refresh action stays busy — the only
recovery is a page reload.
### Steps to Reproduce
1. Open Metrics Explorer and wait for the profile panels to load.
2. Type a PromQL expression in the custom query box and press Run, so the
request is still in flight (a slow Prometheus makes the window easy to hit).
3. While the request is running, switch the display language in the top bar.
4. Observe that the custom panel keeps spinning after the query resolves and
that the Run button cannot be clicked.
Deterministic form, no timing needed:
`web/src/components/__tests__/MetricsExplorer.test.tsx` › `keeps the pending
custom query when the display language changes` holds the `queryMetrics`
promise open, switches the language through `LangContext.setLang('en')` and
then resolves it. On 1ef5d860 it fails with `Unable to find an element with the
text: cluster=prod / query=custom`.
### What Did You Expect to See?
The display language is a presentation concern, so switching it should not
touch query state: the in-flight custom query should publish its result as
usual, and the profile list and profile panels should not be refetched.
### What Did You See Instead?
- `runCustomQuery` marks the panel loading and publishes only while its
request generation is current; the two publishes are the only places that clear
the loading flag.
- The profiles effect ends with a cleanup that bumps the panel generation
**and** the custom-query generation, while its body only restarts the panel
flow through `loadAll(...)`. The custom flow is restarted only by the
instance-transition and data-source-fallback paths.
- The effect's dependency chain reaches language-dependent values
(`copy.defaultDataSource`, `copy.customTitle`, `queryErrorFallback`), so a
language switch re-runs it. The custom generation is bumped, the in-flight
result fails its freshness guard, and nothing restarts that flow.
- The same re-run also refetched the metric profile list and re-queried
every profile panel, one Prometheus request per panel.
### Additional Context
- Same visible symptom as #3304 (Metrics Explorer panels frozen on their
spinners) but a different mechanism: #3304 was the request counter shared by
the refresh handler, fixed by #3299 by giving the two flows independent guards.
This report covers the profiles effect re-running for a reason unrelated to the
query, which still invalidates the custom flow.
- Fix and regression test: #4888.
--
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]
