zmuxuny opened a new issue, #6030: URL: https://github.com/apache/rocketmq-dashboard/issues/6030
### 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 4ee173ad71ae777f01111394a88358958b9abad6 (current canonical branch in CONTRIBUTING.md). ### Runtime Environment Linux, Temurin JDK 21, Maven 3.9.11. Reproduced with isolated backend regression tests using mocked I/O and the real RocketMQ 5.5.0 TopicPublishInfo queue selector. No MySQL or live broker is required for this reproduction; no live-cluster E2E result is claimed. ### Connected RocketMQ Cluster Apache provider; RocketMQ client 5.5.0. Relevant deployment: an original FIFO topic with multiple writable queues, and dead letters carrying MessageConst.PROPERTY_SHARDING_KEY (__SHARDINGKEY). ### Build Toolchain _No response_ ### Describe the Bug ## Tracking continuation (2026-10-10) This replaces #5191, which was automatically closed by github-actions[bot] for inactivity on 2026-10-08. The issue's technical/design scope is preserved. Its current discussion and related issue/PR searches were rechecked before creating this continuation; no existing replacement issue was found. Existing fix PR #5192 remains open and ready for review. This replacement restores issue tracking for that PR without creating another implementation. The original report below retains its stated baseline and historical verification. It does not claim fresh test results, fully green CI, or new maintainer approval. Discussion and prior evidence remain available in #5191. Both time-range and selected-message DLQ replay call RocketMQDLQProvider.resendAll -> resendOne. The reconstructed message retains its FIFO message-group property, but resendOne always calls producer.send(message). The classic client ordinary send path chooses queues independently of that group. Consequently, messages from one FIFO group can be replayed into different queues and processed concurrently or out of replay order, while Studio reports all sends as successful. The existing normal-message send implementation already chooses queues by the explicit message-group hash; the DLQ path does not. ### Steps to Reproduce 1. Prepare four DLQ messages for the same original orders topic, in group order order-a, polygenelubricants, order-a, polygenelubricants. Each contains __SHARDINGKEY and PROPERTY_DLQ_ORIGIN_TOPIC=orders. 2. Provide a target route with three writable queues. 3. Replay selected IDs using POST /api/dlq/resend-selected without a target override. The same defect occurs with POST /api/dlq/resend and an explicit compatible FIFO target. 4. Observe the producer overload and selected queues: ordinary send ignores the group and cycles through queues. The deterministic test runs the actual SDK TopicPublishInfo.selectOneMessageQueue() for ordinary send and executes the supplied selector for group-aware send. Both selected-ID and time-range cases fail on unchanged production: Tests run: 2, Failures: 2, Errors: 0, Skipped: 0 resendMessagesKeepsEachFifoGroupOnOneQueueTest(false): same group routed to different queue IDs resendMessagesKeepsEachFifoGroupOnOneQueueTest(true): same group routed to different queue IDs ### What Did You Expect to See? Preserve the original FIFO group property and use deterministic group-based queue selection when that property is nonblank. Ungrouped dead letters keep ordinary send behavior. A failed group-aware send must not fall back to ordinary send. This is a bounded queue-affinity fix. It does not reconstruct original application ordering, coordinate concurrent replay requests, or promise stable routing across topology changes. ### What Did You See Instead? The group property survives, but all four messages use the ordinary producer overload. Replay returns matched=4, resent=4, failed=0, outcome=SUCCESS while repeated messages for each group land in different queues. ### Additional Context Sources: - [Studio resend path](https://github.com/apache/rocketmq-dashboard/blob/4ee173ad71ae777f01111394a88358958b9abad6/server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQDLQProvider.java#L552-L609) - [RocketMQ 5.5 producer send path](https://github.com/apache/rocketmq/blob/98799686a99c85537cf0a13648b0b521bd16a6b1/client/src/main/java/org/apache/rocketmq/client/impl/producer/DefaultMQProducerImpl.java#L738-L789) - [SDK queue selector](https://github.com/apache/rocketmq/blob/98799686a99c85537cf0a13648b0b521bd16a6b1/client/src/main/java/org/apache/rocketmq/client/impl/producer/TopicPublishInfo.java#L79-L102) - [Broker DLQ construction](https://github.com/apache/rocketmq/blob/98799686a99c85537cf0a13648b0b521bd16a6b1/broker/src/main/java/org/apache/rocketmq/broker/processor/AbstractSendMessageProcessor.java#L157-L232) - [FIFO contract](https://rocketmq.apache.org/docs/featureBehavior/03fifomessage/) All-state searches covered DLQ/FIFO/ordered/order/SHARDING_KEY, dead-letter ordering, replay ordered, and resend/redelivery group/selector/sharding. Related #4421/#4422 and #4847 concern normal topic-send feature/input handling; this report concerns the DLQ replay path. #5035 concerns DLQ analysis/replay-policy suggestions, not group-aware producer routing. Prepared with AI assistance; regression tests were actually run against the stated revision. No production edit has been made before opening this report. ### 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]
