zmuxuny opened a new issue, #5031: URL: https://github.com/apache/rocketmq-dashboard/issues/5031
### Before Creating the Bug Report - [x] I searched open and closed issues/PRs for broker config preview, partial apply, and stale config state. #4165 concerns competing preview requests; this happens after a configuration mutation, including when there is only one preview. - [x] This is a RocketMQ Studio defect. - [x] Reproduced against `rocketmq-studio` at `0228dad` using the current frontend code and a controlled `PARTIAL` response. ### Studio Version Branch: `rocketmq-studio`; commit: `0228dad` (2026-09-23). Frontend built from source. ### 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 failure is in the page's handling of that response and can be reproduced with a mocked service. ### 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. This matters because 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 `web/src/pages/cluster/index.tsx` has a generation guard for preview-vs-preview races, but `handleConfigSubmit` does not invalidate it. The existing `PARTIAL` branch refreshes data and returns without closing the modal or clearing its preview. This is separate from #4165, whose exact preview-vs-preview race is already guarded in the current code. ### Are You Willing to Submit a Pull Request? - [x] Yes. -- 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]
