zmuxuny opened a new issue, #6061: URL: https://github.com/apache/rocketmq-dashboard/issues/6061
### 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 Source inspected at PR #5202 head ec162a40181abaa39e8804373733efb31d121f68, using RocketMQ 5.5.0. Source-path analysis, not a claimed live-broker/UI reproduction. ### Runtime Environment Apache Studio web message page plus RocketMQ 5.5.0 client decoding; source inspection and maintainer review. No live deployment result is claimed. ### Connected RocketMQ Cluster Apache provider path. A message with distinct producer UNIQ_KEY and physical broker offset ID. ### Build Toolchain _No response_ ### Describe the Bug ## Summary The Apache Studio UI can publish a producer `UNIQ_KEY` as `MessageRecordVO.msgId` and send that value to direct consumption, where it is interpreted as a physical broker offset ID and rejected before message lookup. This is separate from #6031 (originally #5199) and PR #5202, which correct the identity of an already-resolved SDK message for callers that already hold a physical offset ID. This follow-up is requested in https://github.com/apache/rocketmq-dashboard/pull/5202#pullrequestreview-5477881084. No API expansion is included in #5202. ## Evidence and affected path Inspected PR #5202 head `ec162a40181abaa39e8804373733efb31d121f68` using RocketMQ 5.5.0: 1. `RocketMQMessageProvider.toRecordVO` publishes `messageExt.getMsgId()`. 2. RocketMQ client decoding returns `MessageClientExt`; when `UNIQ_KEY` exists, `getMsgId()` returns that producer ID while `getOffsetMsgId()` retains the broker location. Pull results use client decoding too. 3. `web/src/pages/instance/message.tsx` sends the selected message's `msgId` to direct consumption. 4. `requireDirectMessageTarget(target, messageId, false)` runs before `viewMessage`. A producer ID which does not identify a target master is rejected with 409 at that first guard. This report is source-path analysis corroborated by the maintainer review, not a claimed live-broker/UI reproduction. ## Expected result and design decision Direct consumption initiated from a listed Apache message should carry an unambiguous physical message identity while retaining all ownership, route, topic, and store-host checks. Please agree on the public contract before implementation: whether `MessageRecordVO.msgId` should remain a producer/logical ID with a separate explicit physical ID, or whether the published field's semantics should change with a compatibility plan. Update `docs/api-spec.md` consistently; its current 20-hex sample does not represent either supported ID form. Cloud-provider IDs must retain their provider-specific semantics. ## Acceptance criteria - Decide and document logical versus physical IDs in the message response and direct-consume request. - Cover encode/clientDecode with distinct `UNIQ_KEY` and offset ID, publish through `toRecordVO`, and carry the selected identity through the UI request. - Prove a valid owned Apache message reaches the SDK direct-consume call with its physical ID. - Keep malformed/foreign physical IDs and topic/store-host mismatches fail-closed before the write. - Cover messages without `UNIQ_KEY`, plain `MessageExt`, and cloud-provider compatibility. Searches for direct consumption + UI, direct + physical, and direct + UNIQ_KEY found #5199/#6031 for the resolved-message defect and #4375 for cloud-provider support, but no issue specifically tracking this published-ID/UI contract gap. AI assistance was used for source inspection and this report. ### Steps to Reproduce Source-path trace: decode a message with distinct UNIQ_KEY and offset ID as MessageClientExt; toRecordVO publishes getMsgId(); web/src/pages/instance/message.tsx submits that msgId for direct consumption; requireDirectMessageTarget(target, messageId, false) checks it before viewMessage. The logical producer ID cannot identify the physical broker target. An end-to-end regression should cover this exact path; no live UI reproduction is claimed. ### What Did You Expect to See? A listed Apache message should carry an unambiguous physical identity into direct consumption while preserving ownership, route, actual-topic and store-host checks. Agree the API field semantics and compatibility policy before implementation. ### What Did You See Instead? The UI can submit producer UNIQ_KEY as if it were a physical offset ID and receive 409 at the initial guard, before lookup. PR #5202 only corrects the later already-resolved SDK message identity for callers already holding physical offset IDs. ### Additional Context Follow-up requested in https://github.com/apache/rocketmq-dashboard/pull/5202#pullrequestreview-5477881084. Separate from #6031 (original #5199); no competing implementation PR is being opened. ### Are You Willing to Submit a Pull Request? - [ ] 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]
