Aias00 opened a new issue, #784: URL: https://github.com/apache/rocketmq-dashboard/issues/784
### Before Creating the Bug Report - [x] I have confirmed this is not already covered by an existing issue or open pull request. ### Describe the Bug The Studio cluster management APIs acknowledge several broker, NameServer, and proxy operations as successful even though no real RocketMQ infrastructure operation is executed. For example, the backend validates that a cluster or node exists, logs messages such as "restart initiated" or "deleted", and returns `true`/success. The corresponding UI then displays a success toast, which can make operators believe that a restart, upgrade, delete, or config change was applied to the real cluster. Affected behavior includes: - Broker restart - NameServer update/restart/upgrade/delete - Proxy restart - Cluster config update that only mutates the in-memory/repository view ### Steps to Reproduce 1. Open the Studio cluster management page. 2. Trigger a broker restart, proxy restart, or NameServer operation for an existing mocked/configured node. 3. Observe that the API returns success and the UI displays a success notification. 4. No real broker, NameServer, or proxy operation is performed. ### What Did You Expect to See? Until a real provider/executor is wired, unsupported operational actions should return an explicit unavailable/unsupported response so the UI does not report fake success. ### What Did You See Instead? The backend returns success after local validation/logging only. ### Additional Context This is part of the Studio control-plane baseline/ARCH-01 hardening: UI actions should be capability/provider driven and must not expose successful no-op operations. -- 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]
