Frun1na opened a new issue, #4808: URL: https://github.com/apache/rocketmq-dashboard/issues/4808
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) and found no similar issue. ### What Happened `docs/api-spec.md` section 4 (cluster / NameServer / Proxy) documents request fields and response shapes the controllers do not have: - 4.3 `POST /api/clusters/config/update` documents the response as `ClusterInfo`, but the controller returns `ClusterConfigUpdateResultVO` (`{cluster, status: SUCCESS/PARTIAL/FAILED, successfulBrokers, failedBrokers}`). - 4.4 broker restart documents `{success: boolean, message: string}`; the endpoint returns only `{message}` and reports failure by throwing, never `success: false`. - 4.6 NameServer update documents a `newAddr` request field that does not exist anywhere in the codebase (the DTO takes `{clusterId, addr, version?}`), and documents a `NameServerInfo` response where the controller returns `Result<Void>`. - 4.7 / 4.8 / 4.9 / 4.11 omit the required `clusterId` (and 4.8's required `targetVersion`) from the request bodies, and document `{success: boolean}` responses where the controllers return `Result<Void>`. Following the request bodies in the document, integrators would omit required fields (their requests fail validation with 400) and then look for a `success` field in `data` that never appears. ### Expected Behavior The section should match the controllers: request bodies listing every required DTO field with its validation annotations, and responses describing `Result<Void>` (failure through the error response) or the real `ClusterConfigUpdateResultVO` shape. -- 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]
