zmuxuny opened a new issue, #6374: URL: https://github.com/apache/rocketmq-dashboard/issues/6374
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version `rocketmq-studio`, commit `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`, source checkout. ### Runtime Environment Linux, Node.js 24.19.0, Vitest/jsdom. Reproduced using the real DashboardPage and MetricsExplorer components with their separate service/API boundaries mocked. This report does not claim a live-browser or live-cluster reproduction. ### Connected RocketMQ Cluster Not required for the deterministic reproduction. The selected instance and Prometheus data source remain unchanged. Only the overview/dashboard read fails; metrics query responses remain successful. ### Build Toolchain _No response_ ### Describe the Bug An operator can lose an in-progress PromQL investigation just because the separate cluster overview refresh fails. The error branch replaces the whole dashboard subtree, unmounting MetricsExplorer. Its selected Prometheus source, time range, committed custom query, chart, and unsaved query draft are destroyed. Retrying the overview recreates an empty explorer with the default source and 1h window. Prometheus is independently queried and can remain usable, for example when current broker overview RPCs fail but historical metrics are still available. The overview error should not disable that independent diagnostic path. ### Steps to Reproduce 1. Open the dashboard and select one instance. 2. Select a healthy named Prometheus source, choose 6h, and run a custom PromQL expression. 3. Edit another expression in the custom query textarea without running it. 4. Refresh the cluster overview using the page-header Refresh button. Let only this overview request fail. 5. Observe that the entire Metrics Explorer disappears. Retry the overview successfully. 6. Observe that the query draft is empty, the custom result is gone, the metrics source is default, and the range is 1h. ### What Did You Expect to See? The overview's failure and retry must leave the independent metrics editor mounted for the same instance. Display the overview error with its existing retry action while preserving the metrics source, selected window, committed query, current result, and unsaved draft. Metrics queries should still run if their own backend is available. ### What Did You See Instead? - `web/src/pages/home/dashboard.tsx:152-178` returns separate loading/error trees that omit MetricsExplorer. - MetricsExplorer appears only at the bottom of the successful overview tree. - The state inside MetricsExplorer is local to its mount, so the overview failure destroys it even though neither its instanceId nor selected data source changed. Two integration regressions on the original production code reproduce this: - After overview failure, the actual custom-query textbox cannot be found. - After successful overview Retry, the draft expected to be `sum(rate(messages_total[5m]))` is an empty string. The fixture holds instance-a and Prometheus A fixed. The default metrics and named-source query APIs continue returning successful matrices throughout. The tests do not mock MetricsExplorer. ### Additional Context Searched issues and PRs for dashboard unmount, dashboard stale data, metrics reset, and visibleDashboard. #4188/#4189 and #4264/#4265 address query context when a mounted MetricsExplorer receives a changed instance prop; they do not prevent the parent from destroying an editor after an unrelated overview request fails. This reproduction does not change instances. Further duplicate checks covered both issues and PRs with these repository-scoped searches: `dashboard unmount`, `dashboard visibleDashboard`, `dashboard stale`, `metrics reset`, `dashboard refresh metrics`, `dashboard error editor`, `DashboardPage error`, and `dashboard error MetricsExplorer`. Other nearby changes are also distinct: - #4655 / #4659 recover MetricsExplorer after its own metric-profile request fails; this report keeps profile and metrics requests successful and fails only the overview service. - #3304 / #3299 separate profile/custom query generations so simultaneous refreshes complete; the current report is the parent unmounting both flows entirely. - #4893 / #4888 prevent a language change from invalidating in-flight metrics work; no language change occurs here. - #1288 protects dashboard data from stale responses after an instance change. The proposed correction must retain those overview protections. The fix should retain existing overview stale-data protections, preserve current no-instance/instance-switch cleanup behavior, and avoid making another instance's results appear under a new selection. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
