zmuxuny opened a new issue, #6185: URL: https://github.com/apache/rocketmq-dashboard/issues/6185
### 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@5e4c39b0, verified 2026-10-10. ### Runtime Environment Deterministic AlertsPage component tests with real React Router history navigation and mocked API responses. No live alert configuration was changed. ### Connected RocketMQ Cluster Not applicable to live cluster connectivity: frontend alert-domain session state, reproduced with mocked API. ### Build Toolchain _No response_ ### Describe the Bug Cluster and business alert routes reuse AlertsPage. Browser history navigation between routes resets list filters and loads the new domain's rules, but leaves the previous domain's editor open with its old rule and form values. The save handler selects the API using current domain. A diagnostic test confirms that submitting the retained Cluster rule id 1 invokes updateAlertRule with that cluster payload and BUSINESS domain. This proves a wrong-domain client request in the mocked harness; it does not establish that a server accepts the write. A delayed old-domain dry-run result can also populate a newly opened editor in the new domain. ### Steps to Reproduce 1. Visit Business Alert Rules, then Cluster Alert Rules. 2. Open a cluster rule for editing. 3. Use browser Back while the modal is open. 4. The business rule list loads, but the cluster rule's edit modal remains open. 5. Submitting the retained form selects the BUSINESS API domain with the old cluster rule identity. Regression uses MemoryRouter initial entries ['/ops/business-alerts', '/ops/alerts'] at index 1 and navigate(-1), rather than only changing props. ### What Did You Expect to See? Editor state and asynchronous work belong to the domain where they were opened. Domain changes must discard the old editor session before stale forms become actionable. Delayed completions from the old domain must not affect a new editor. Same-domain navigation should preserve in-progress editing. ### What Did You See Instead? Against unchanged production source: - Original Back regression: 1 failed, 30 skipped; business rules loaded while the previous editor remained. - Expanded session cases: 3 tests, 2 failures and 1 pass. Failures cover retained old editor and old CLUSTER pending dry-run overwriting a new BUSINESS editor; same-domain query navigation preservation passes. - Separate diagnostic assertion that updateAlertRule receives Cluster rule id 1 plus BUSINESS domain passes (1 passed, 30 skipped), confirming the wrong-domain client call. No server-side acceptance or production write is claimed. ### Additional Context ### Source and regression In web/src/pages/ops/alerts.tsx, renderedDomain adjustment around line 190 resets list state but not editor/session state; handleSubmit around line 808 selects the API from the new domain. Original regression command: `npm test -- src/pages/ops/__tests__/AlertsPage.test.tsx -t 'browser history switches'` ### Duplicate check - #4004 / #4008 reset domain list filters, pagination and selection, not editor state. - #4584 / #4583 clear a prior completed dry-run result on Edit, not a modal retained across routes. - #4875 / #5542 guard runtime/effect results, not editor identity. - #4518 disables stale list-row mutations during reload. Open and historical searches found no editor-session domain boundary fix. ### Acceptance criteria - Back/Forward between domains closes the old editor. - New domain starts with clean editor state. - Pending old-domain work cannot overwrite or close a new editor. - Same-domain create/edit/duplicate/test flows stay functional. - Regression coverage uses actual router history navigation. AI assistance was used for source inspection and deterministic route-level regression authoring. ### 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]
