zmuxuny opened a new issue, #7175: URL: https://github.com/apache/rocketmq-dashboard/issues/7175
### 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 rocketmq-studio at 127c47b06a268cc74224d5f34c56ec7c36ac0d55. This report targets the Studio development branch, not the legacy master branch. ### Runtime Environment Frontend reproduction with the actual AlertsPage and Ant Design controls in Vitest 4.1.10/jsdom, Node.js 24.19.0 on Linux. No live cluster or database is required for the editor defect. ### Connected RocketMQ Cluster Not applicable: the defect occurs locally in the alert-rule editor before any RocketMQ operation. Service calls are mocked in the component regressions. ### Build Toolchain _No response_ ### Describe the Bug The notification-template textarea has maxLength=4000, but its variable buttons use form.setFieldValue and can produce a longer controlled value. The field has no validation rule, so Save and Test Run do not reject that value locally. AlertRuleRequestDTO already rejects notificationTemplate values longer than 4000 UTF-16 code units. The preview warning is informative only and does not prevent the invalid submission. ### Steps to Reproduce 1. Edit an otherwise valid alert rule whose notification template contains 3995 ordinary characters. 2. Put the caret at the end and click the ${ruleName} variable button. 3. The template now contains 4006 characters, despite the textarea limit. 4. Try Save or Test Run. The form validation permits the oversized payload instead of identifying the invalid field. The same boundary is reachable with supplementary Unicode characters: 2000 rocket emoji occupy 4000 UTF-16 code units before inserting any variable. ### What Did You Expect to See? Preserve the complete editor text so it can be corrected, show a localized field-level length error, and prevent Save/Test Run from submitting it until it satisfies the existing server limit. Selection replacement that leaves exactly 4000 UTF-16 code units must remain valid. ### What Did You See Instead? Variable insertion grows the field beyond its limit without a form error. Both submit handlers only call form.validateFields(), and the template Form.Item has no rule. The existing preview can warn, but it is not a submission constraint. ### Additional Context Seven actual-control regressions were exercised against unchanged production code: five overflow/recovery cases fail because the field error is missing, while two exact-limit replacement controls pass. The bounded local correction passes all seven; the full related run passes 119 tests across 10 files, with TypeScript and changed-file ESLint/Prettier checks passing. The fix needs UTF-16 length parity with Java @Size and the textarea. The installed async-validator string max rule counts supplementary code points differently, so simply adding max:4000 is insufficient. Related #3038 added the preview; #6664 addressed replacement parity. Neither adds submission validation for inserted templates. AI assistance was used for investigation and regression testing. ### 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]
