zmuxuny opened a new issue, #6359: URL: https://github.com/apache/rocketmq-dashboard/issues/6359
### 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 Metrics query history is ordered differently while the explorer is open and after it is reopened. Live updates prepend every successful response in completion order, while loading persisted history sorts by the recorded query time. A slow older profile query can therefore jump ahead of a newer custom query. The live merge also applies the 12-entry cap before ordering, allowing an older late result to evict a newer query permanently. ### Steps to Reproduce 1. Open Metrics Explorer and leave one profile-panel request pending. 2. A second later, run a custom query and let it complete. 3. Resolve the earlier profile request. 4. Open Query history. The older profile entry is first, above the later custom entry. 5. Reopen the explorer. Loading the same entries reverses their order to newest query first. The component regression uses deferred promises and the recorded query-start clock; both requests succeed with normal metric data. A separate unit regression supplies a full recent history and an older late completion, then verifies that the 12 most recent queries survive. ### What Did You Expect to See? Apply the same newest-query-first ordering during live updates and persistence loading, and apply the entry cap after that ordering so it retains the most recent queries. Keep identity-based deduplication. ### What Did You See Instead? - `MetricsExplorer.tsx:611` records `queriedAt` before awaiting the request. - Profile panels execute concurrently (lines 657-660), and profile/custom flows merge their histories on completion (lines 694-697 and 804-807). - `metricsExplorerDiagnostics.ts:500-503` prepends the completion and immediately slices the list. - Loading that history sorts by descending `queriedAt` first (lines 428-432). The red component test expects `[custom, profile]` but gets `[profile, custom]` after the older request resolves. Unit coverage proves an old completion displaces a more recent entry at the limit. ### Additional Context This does not change which query response is allowed to update its chart. The existing independent profile/custom request guards remain intact. The fix is confined to stable history ordering and limiting. Regression coverage should cover out-of-order successful completions, the 12-entry limit, existing deduplication, deterministic equal timestamps, and consistency after persistence reload. Verified red on unchanged production: the real component's parallel-success case fails on [profile, custom] order, and pure merge regressions fail on chronology and retention. 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]
