zmuxuny opened a new issue, #6370: URL: https://github.com/apache/rocketmq-dashboard/issues/6370
### 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 Branch `rocketmq-studio`, commit `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`. Reproduced using the real Topic page and Send Message modal against synthetic service responses; no live deployment. ### Runtime Environment Linux workspace, Node.js 24.19.0, repository-pinned Vitest 4.1.10, React 18, Ant Design 5.29.3 and jsdom. No database or broker is required for the frontend reproduction. ### Connected RocketMQ Cluster No real cluster was used. The send service is mocked and records the outgoing request without publishing a message. All topics, bodies and property values are synthetic. ### Build Toolchain _No response_ ### Describe the Bug The Topic Send Message dialog silently removes leading and trailing whitespace from nonblank custom-property values entered in its separate key/value form fields. For example, the property-value input still contains `" tenant-blue "` when Send is pressed, but the request passed to `sendTopicMessage` contains `"tenant-blue"`. Unicode whitespace is also removed: `" 租户一 "` becomes `"租户一"`. This changes the message being published rather than only formatting its preview. A consumer reading a business property receives a different string, so exact comparisons and payload-fidelity tests cannot be reproduced through the console. The body is already preserved verbatim, and there are explicit informational notices for Tag/Key trimming; no equivalent notice explains this custom-property mutation. ### Steps to Reproduce 1. Open Topic management and open Send for an existing Topic. 2. Enter an ordinary nonempty message body. 3. Add a custom property with name `tenant` and value ` tenant-blue `, including two spaces on each side in the separate value input. 4. Press Send and inspect the outgoing properties map at the service/API boundary. 5. The field contains the original value but the outgoing map contains the trimmed value. ### What Did You Expect to See? Nonblank business-property values entered in dedicated form fields should reach the send service unchanged, including their surrounding whitespace. The preview byte counts should describe those same values. ### What Did You See Instead? `buildMessagePropertiesFromRows` assigns `const value = rawValue.trim()`. `analyzeMessagePayloadPreview` returns that altered value in its `properties` map, and `handleSend` submits the map. The field itself is not changed, so the difference is not obvious to the operator. ### Additional Context Source path at the reproduced revision: - [Form-property normalization](https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/web/src/utils/messagePayloadPreview.ts#L158-L196). - [Send uses the preview properties](https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/web/src/pages/instance/topic.tsx#L1505-L1538). - [The Apache sender passes each value through unchanged](https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQAdminClientImpl.java#L535-L545). The upstream [RocketMQ Message implementation](https://github.com/apache/rocketmq/blob/develop/common/src/main/java/org/apache/rocketmq/common/message/Message.java) checks whether a value is blank but stores the original value, and the [property codec](https://github.com/apache/rocketmq/blob/develop/common/src/main/java/org/apache/rocketmq/common/message/MessageDecoder.java) appends and decodes the value without trimming it. Whitespace surrounding otherwise nonblank content is consumer-observable data. The real-component regression does not mock the form, preview utility or submit handler. It opens Send, fills the actual property inputs, verifies the input's exact value, clicks Send and examines the mocked service request. On unchanged production: 2 failures (ASCII and Unicode padded values), 1 passing control (ordinary unpadded value). The service is called exactly once in all three cases. Focused reproduction: `cd web && node node_modules/vitest/vitest.mjs run src/pages/instance/__tests__/TopicPage.test.tsx -t 'preservesTheExact.*FormPropertyValue' --maxWorkers=1` The proposed change is limited to nonblank values in the dedicated form mode. Keep property-name normalization, duplicate detection, blank-row/empty-value behavior, reserved-key handling and the existing batch-text parser grammar unchanged. Test whitespace-only values explicitly rather than silently expanding their accepted semantics. No CSV or wire-separator handling changes are needed. Related work checked: - #3064 introduced the payload preflight and normalization but does not specify trimming nonblank custom-property values. - #2200 / #2154 validate malformed and duplicate batch lines; they do not address value preservation in form fields. - #2706 / #2701 preserve commas in batch values; this report does not change that parser. - #6064 validates RocketMQ wire separators at the backend and preserves encodable values; ordinary surrounding spaces are not separators. - #4777 / #4774 preserve original message bodies in downloads/copies, a separate field and path. ### 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]
