zmuxuny opened a new issue, #5550: URL: https://github.com/apache/rocketmq-dashboard/issues/5550
### 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 Originally reproduced on `rocketmq-studio@0228dad` (2026-09-23), frontend built from source. The current fix PR #5032 records fresh 2026-10-04 validation against `rocketmq-studio@6a68042fa73a513f40436ca721944b4de48181ec`. ### Runtime Environment Frontend in the repository's Vitest/jsdom test environment. The same state path runs in the browser; no database or specific OS is involved. ### Connected RocketMQ Cluster A cluster with multiple Brokers, where `updateClusterConfig` succeeds on one Broker and returns `PARTIAL` because another Broker fails. The page's handling of that response can be reproduced with a mocked service. ### Build Toolchain _No response_ ### Describe the Bug The Broker configuration modal keeps a preview of the pre-update state after a partial cluster config update. `handleConfigSubmit` refreshes the cluster list and leaves the modal open on `PARTIAL`, but never clears `configPreview` or invalidates an in-flight `previewClusterConfig` request. The panel may therefore show a diff calculated before some Brokers were changed. A late preview response can also repopulate the panel after the partial update. The preview is the operator's safety check before deciding how to recover a partial cluster write. A stale diff can make a second application appear to target the same state on every Broker when the cluster has already diverged. ### Steps to Reproduce 1. On the Cluster page, open a Broker's configuration modal and change a value. 2. Generate a preview. 3. Submit the update while the backend returns `PARTIAL` (one Broker updated, one failed). 4. Observe that the modal stays open with the old preview still displayed. If the preview request was still in flight at step 3, resolve it after the partial response; it can also fill the panel with stale data. ### What Did You Expect to See? After any non-successful mutation that may have changed Broker state, the old preview should be invalidated. The operator can request a fresh preview against the new state before retrying. ### What Did You See Instead? The pre-update preview remains visible, or a late response restores it, even though at least one Broker was already updated. ### Additional Context ### Previous report and current fix (2026-10-04) This replaces [#5031](https://github.com/apache/rocketmq-dashboard/issues/5031), automatically closed by `github-actions[bot]` for inactivity on 2026-10-04. The closure was a stale-workflow action, not a maintainer rejection of the reported defect. The existing fix PR is [#5032](https://github.com/apache/rocketmq-dashboard/pull/5032), which remains open. October 4 validation, dated CI results, and remaining limitations are recorded there. Overall CI is not green. ### Historical verification (2026-09-26) The September 26 report recorded 31 focused frontend tests passing. These are historical; fresh October 4 validation is in #5032. ### Scope and related reports `web/src/pages/cluster/index.tsx` has a generation guard for preview-vs-preview races, but the reported `handleConfigSubmit` path does not invalidate it. The `PARTIAL` branch refreshes data and returns without closing the modal or clearing its preview. #4165 concerns preview-vs-preview ordering; this issue is the configuration mutation boundary, including when there is only one preview. #3103 concerns selecting the correct target instance for Broker actions. The existing fix also blocks new previews while a write is pending. ### 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]
