zmuxuny opened a new issue, #6357: URL: https://github.com/apache/rocketmq-dashboard/issues/6357
### 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 - Branch: `rocketmq-studio` - Commit: `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6` - Verified against a source checkout with frontend component/unit tests. ### Runtime Environment Linux, Node.js 24.19.0, the repository's installed Vitest/jsdom stack. All API calls in the reproduction are mocked. This report does not claim a live-browser or live-cluster reproduction. ### Connected RocketMQ Cluster Not required. The defect is in frontend query state and reproduces with ordinary successful metrics responses. ### Build Toolchain _No response_ ### Describe the Bug A query history entry records its data-source key, but if that key is no longer in the available source list, Restore silently falls back to the default Prometheus source. A user restoring a production query can therefore see results from a different backend. The action also replaces the currently active source, profile, and time window without explaining that the original source is unavailable. This is a result-correctness issue. It does not depend on authentication or an access-control bypass. ### Steps to Reproduce 1. Run a metrics query against a named source and retain the history entry. 2. Remove that source in Settings, then reopen Metrics Explorer so the configured source list is current. 3. Select another available source, open Query history, and restore the entry for the removed source. 4. Observe the request destination and the source shown after restoration. Deterministic component reproduction seeds an ordinary history entry for `removed-source`, serves a source list containing only `active-source`, activates that source, then clicks Restore. Both profile and custom-query history entries reproduce it. ### What Did You Expect to See? If an entry names a source that cannot be restored, explain that it is unavailable and preserve the active source, profile, range, custom query, and result. Do not issue a query against a substitute source. Entries deliberately using the default source should still restore normally. ### What Did You See Instead? `handleRestoreHistory` finds no matching source and turns that absence into the default key: - `web/src/components/MetricsExplorer.tsx:1152-1155`: `const nextDataSourceKey = nextDataSource?.key ?? '';` - Both restore branches pass this key to `activateDataSource`, which updates the selected source and launches queries. - `runQuery`, lines 623-632, selects the default `queryMetrics` API when the key is empty. The red component tests start with one initial default request. Restoring profile history produces a second default request; restoring custom history produces two additional default requests (the current profile and the custom expression). No unavailable-source message prevents the change. ### Additional Context Related changes handle different situations: #5797 preserves state when a history profile was removed; #6060 cancels an authentication prompt when an instance change makes its pending source unavailable. Neither handles restoring an entry for a missing named source. Regression coverage should include profile and custom entries, a source unavailable in the current instance, preservation of an already selected source and query, and successful restoration of an explicitly default-source entry. Verified red on unchanged production: the two real-component restore tests fail on the extra default-source API requests, not on a timeout. No production fix or full-suite pass is claimed yet. AI assistance was used for investigation and test preparation. ### 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]
