unbridled-41 opened a new issue, #5462: URL: https://github.com/apache/rocketmq-dashboard/issues/5462
### Studio Version branch: `rocketmq-studio` @ `6a68042f` (the revision verified; the branch is based on it) deployed as: built from source (unit test) ### Runtime Environment Not environment-specific: frontend form behaviour against the existing backend validation. ### Connected RocketMQ Cluster An Apache instance whose broker is opened in the cluster page's config dialog. ### Describe the Bug The broker config dialog exposes 写队列数 and 读队列数 as two independent inputs whose shared tooltip says they must match, but **neither input is validated** and the submit path always sends both (`buildConfigUpdateRequest` spreads the whole form). Editing one of them therefore submits the other's stale value, and `ClusterService.requireMatchingDefaultQueueNums` rejects the mismatched pair with `400` for preview, update and propose alike. The dialog then reports it as "Broker 配置更新失败，请检查：" with an empty broker list — the operator gets no hint of the cause. The backend already supports the single-field edit: `applyConfig` mirrors whichever count is supplied onto the other, so a partial update matches the broker's single `defaultTopicQueueNums` property (commit `248e3869`, #1075). The console simply never sends one. ### Steps to Reproduce 1. Open a broker's 配置 dialog. 2. Change only 写队列数 from 8 to 16 and press 预览 (or 确定). 3. Observe the failure with an error message that names no problem. ### What Did You Expect to See? Editing one of the two counts either succeeds (the broker has a single queue-count property) or is refused with the reason stated on the field. ### What Did You See Instead? A 400 rendered as "…请检查：" with nothing after the colon. ### Evidence - `web/src/pages/cluster/index.tsx` (the two `Form.Item`s and `buildConfigUpdateRequest`), `cluster/broker/ClusterService.java` (`requireMatchingDefaultQueueNums`, called by preview/update/propose). - `cd web && npx vitest run src/pages/cluster/__tests__/ClusterPage.test.tsx` — the added case `mirrors a queue-count edit onto its pair instead of submitting a mismatched pair` fails before the change (`Expected the element to have value: 16, Received: 8`) and passes after (`Tests 31 passed`), asserting both the visible input and the submitted payload. ### Impact A documented edit cannot be completed through the console without guessing that both fields must be typed, and the error message hides the cause. ### Acceptance Criteria - The dialog cannot submit a mismatched pair (either by keeping the fields in step or by refusing to submit). - A regression test pins the submitted payload. Related: #2142 (the earlier report of missing cross-field handling in this editor; its `maxMessageSize` rounding item is a separate defect tracked by #5298). **Corresponding PR:** #5429 -- 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]
