zmuxuny opened a new issue, #6630: URL: https://github.com/apache/rocketmq-dashboard/issues/6630
### 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 @ 779b8c0e7aed2396d3cc72743dcd544ea48e9ae6 ### Runtime Environment Linux x86_64; deterministic real Studio service/provider and RocketMQ SDK reproduction, with network boundaries mocked. ### Connected RocketMQ Cluster Apache RocketMQ 5.5.0 native producer/PushConsumer SDK. Source topic orders, consumer group group-a; default destination %RETRY%group-a. ### Build Toolchain JDK 21, Maven 3.9.11; project tests and Checkstyle. ### Describe the Bug Redelivering an ordinary business-topic message to the default retry topic loses its original topic identity. Studio filters system properties during redelivery and again during native send, but does not establish the trusted RETRY_TOPIC metadata required by the consumer SDK. A successful send therefore reaches the listener as %RETRY%group-a rather than orders, which can break topic-based dispatch. ### Steps to Reproduce 1. Start with a full, exact source MessageRecordVO on orders. 2. Call real MetadataService.redeliverMessage for group-a with either no target override or an explicit %RETRY%group-a destination. 3. Exercise the real ApacheInstanceProvider and native message construction; capture the message at the mocked producer network boundary. 4. Round-trip its properties through RocketMQ wire encoding, then invoke the real DefaultMQPushConsumerImpl.resetRetryAndNamespace SDK logic. 5. Assert the listener-facing topic is orders. Baseline reproduction: three tests, two target failures and one explicit business-topic destination control passing, zero errors/skips. The source fixture includes a stale RETRY_TOPIC value to prevent a fix that blindly trusts arbitrary source system properties. ### What Did You Expect to See? A normal source message redelivered through its consumer group retry topic should retain the original business topic for the native listener. Ordinary custom-property filtering and explicit business-topic sends should remain unchanged. ### What Did You See Instead? Both default retry and explicitly selecting the same group retry topic result in listener-facing topic %RETRY%group-a rather than orders. The explicit business-topic control works. ### Additional Context SDK contract: https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/client/src/main/java/org/apache/rocketmq/client/impl/consumer/DefaultMQPushConsumerImpl.java#L1564-L1575 . This needs a trusted internal redelivery path, not a general relaxation of system-property filtering or a client-bindable HTTP field. Existing #5192 covers FIFO DLQ replay, and #5427 covers display-projection loss; neither restores this native retry-topic identity. Additional retry/DLQ-source and missing-metadata cases should be covered in the fix. No live cluster incident or producer transaction was performed. ### 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]
