project-nju-learner opened a new issue, #7330: URL: https://github.com/apache/rocketmq-dashboard/issues/7330
### 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` (Studio 3.0.0). The baseline comparison compiles the original RocketMQDLQProvider and its interface, loading them before the candidate build's remaining classes. This is a provider comparison, not a full clean deployment of the baseline application. ### Runtime Environment Windows, JDK 21.0.12.1. A Java fixture calls the production provider through real admin, producer and pull-consumer clients. Only database-backed instance wiring and audit persistence are replaced with local adapters. No MySQL or browser was used for the Broker reproduction; UI selection has separate component regression coverage. Build toolchain: JDK 21.0.12.1, Maven 3.9.12, Node.js 23.4.0. This is a runtime selection defect, not a build failure. ### Connected RocketMQ Cluster Official RocketMQ 5.5.0, direct NameServer/Broker access. Isolated ordinary DLQ topics, tested with message indexing enabled and disabled. The Broker advertises `localhost:20911`. A subsequent candidate check used two Brokers in the same cluster, indexing disabled, with the replay target only on Broker A. ### Build Toolchain _No response_ ### Describe the Bug Two physical DLQ records can share one producer `UNIQ_KEY`. Client decoding returns MessageClientExt, whose `getMsgId()` exposes that logical ID. Studio uses it for the DLQ row key and selected replay, and the provider deduplicates the requested IDs. Selecting both records therefore collapses them into one selection. Selected Excel export also filters by this logical ID and cannot distinguish the records. With indexing enabled, the original provider resends A only and reports SUCCESS. With indexing disabled, both records remain readable in the DLQ list, but selected replay resolves neither. ### Proposed contract, validation and related work A local prototype preserves msgId and adds server-generated selectionId plus explicit `selectionType: "queue"`. It resolves a record through the instance's DLQ route, pulls its queue offset, and validates topic, queue ID, queue offset and commit-log offset. The browser echoes the string; legacy ID behavior and existing export scan limits remain intact. No dependency or service is added. Please decide the public identity contract before a PR: the current queue locator/discriminator, separate mutually exclusive selectionIds, or a standard offsetMsgId with explicit interpretation and ownership/returned-identity checks. The prototype is not an approved or uniquely minimal API design. With the same real-Broker fixture, the candidate passes both index settings: select B, then A, then A+B yields cumulative target bodies `[B,A,A,B]`. A wrong commit-log offset or a Broker outside the route produces no replay. A two-Broker check also passes when numeric coordinates are identical on A/B. After a real A+B route fetch, controlled B shutdown makes `[B,A]` return `matched=1, resent=1, failed=0, outcome=PARTIAL, scanIncomplete=true`; target read-back shows only A added. This is a controlled failure experiment, not a claim of general cache consistency. Focused backend tests: 206 passed. Focused frontend tests: 43 passed. Full backend/MySQL, browser end-to-end, ACL, static-topic migration, replica failover and physically aged-message tests were not run. Evidence is retained locally; no upstream CI result is claimed. Related #7018 concerns ordinary-message direct consumption and MessageRecordVO's public ID contract; this report concerns DLQ row selection and does not change MessageRecordVO.msgId. #4913/#4912 addressed incomplete-replay warnings, and #5935/#5936 addressed export shortfalls; neither resolves shared-ID record selection. Existing topology, actual-topic and FIFO safeguards remain part of the required behavior. ### Steps to Reproduce 1. Start an isolated RocketMQ 5.5.0 NameServer/Broker with indexing enabled. Create a source topic, target topic and consumer group. 2. Send two source messages with distinct bodies A/B and a shared producer-generated UNIQ_KEY. Pull them and call `sendMessageBack(message, -1, brokerName)` for each to create genuine DLQ records. 3. List through RocketMQDLQProvider. Confirm distinct queue positions and bodies but identical exposed msgId values. 4. Invoke selected replay with both listed IDs. Pull the target queue and compare the actual payloads with A/B. 5. Repeat with a fresh isolated store and `messageIndexEnable=false`. The fixture uses real routing, listing, lookup, pull, send and target read-back. Excel identity filtering is covered by focused tests rather than a live browser download. ### What Did You Expect to See? Each physical row should be independently selectable: selecting B should replay B; selecting A+B should preserve two selections and process both. Selected Excel export should not include a sibling solely because it shares the producer ID. Unresolved selections must remain visible in the result counts. ### What Did You See Instead? Original provider, selecting both rows: - Index enabled: `selected=1, matched=1, resent=1, outcome=SUCCESS`; target contains A only. - Index disabled: `selected=1, matched=0, resent=0, outcome=PARTIAL`; target is empty despite both rows being listable. ### Additional Context _No response_ ### 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]
