Aias00 opened a new issue, #7206: URL: https://github.com/apache/rocketmq-dashboard/issues/7206
### Before Creating the Bug Report - [x] Searched all-state issues and PRs for empty/missing message bodies and send validation. - [x] This is a RocketMQ Studio defect. ### Studio Version `rocketmq-studio` at `127c47b06a268cc74224d5f34c56ec7c36ac0d55`. ### Runtime Environment Backend source review and local tests on macOS / JDK 21. Reproduction does not require a live broker: the SDK's own message validator rejects a zero-byte body before dispatch. ### Connected RocketMQ Cluster Apache RocketMQ 5.5.0 SDK used by the project. ### Describe the Bug `POST /api/topics/send` validates the topic but allows a missing, null, or empty body. `SendMessageDTO.body` has no constraint and `RocketMQAdminClientImpl.validateMessageSize` only checks the upper bound. The provider turns a null body into an empty byte array, resolves ownership/routes, and obtains a pooled producer. RocketMQ's `Validators.checkMessage` then rejects the empty body, and the pool maps that client-input error to HTTP 502. The API spec already marks body as required, and the frontend preflight already rejects empty payloads. Direct REST clients bypass that frontend check and receive a misleading upstream failure after unnecessary instance/route/client work. ### Steps to Reproduce 1. Submit a valid instance/topic with body omitted, null, or the empty string to `/api/topics/send`. 2. Request validation accepts it and invokes the metadata/provider path. 3. On a reachable owned topic, SDK validation fails on the empty body and the pool reports a 502. ### Expected Behavior Reject missing/null/empty bodies with HTTP 400 before invoking metadata service from REST, and reject empty bodies in direct Apache provider calls before ownership lookup, route checks, or producer resolution. Preserve nonempty payloads byte-for-byte, including whitespace-only text. ### Scope This concerns the message-send boundary, not LLM HTTP error response bodies (#6981), message detail size reporting, or the existing upper payload-size limit. -- 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]
