3219378872 opened a new issue, #5106: URL: https://github.com/apache/rocketmq-dashboard/issues/5106
## Before Creating the Bug Report - [x] I searched the open and closed issues and pull requests and did not find a matching report. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] The exact source revision is stated below. ## Studio Version `rocketmq-studio` at `a562601` (built from source). Not a deployment issue. ## Runtime Environment Linux, OpenJDK 21, Maven. Reproduced by encoding trace contexts with RocketMQ client 5.5.0 `TraceDataEncoder` and parsing them with `RocketMQMessageProvider.getMessageTraceByKey`. The broker `queryMessage` RPC is mocked to return that one trace message. No MySQL, browser, or live NameServer is required to see the mixed timeline. ## Connected RocketMQ Cluster RocketMQ client 5.5.0 trace encoding (`MessageConst.KEY_SEPARATOR` is a single space). No live cluster. The probe uses the production encoder and the production parser. ## Describe the Bug Message trace lookup by business key returns trace contexts for other keys that RocketMQ batched into the same trace message. `TraceDataEncoder` appends every trace context for one source topic and trace topic into a single trace body, and puts every business-key token plus every message id into that message's keys index. `queryMessage` on the trace topic for `order-A` therefore returns the whole batch. `getMessageTraceByKey` then calls `parseTraceBody(..., filterByMsgId=false)`, and the parser keeps every context in the body. A lookup for `order-A` includes `order-B` and `order-A-suffix`. Failed consumption of those other keys shows up as failures on the `order-A` timeline. `order-A` also matches a multi-key column `extra order-A`, which is correct and must keep working. Message-id lookup already drops other message ids and must stay that strict. ## Steps to Reproduce 1. Build six trace contexts with RocketMQ 5.5.0 `TraceDataEncoder`, all on topic `orders`: Pub/SubAfter for key `order-A` (producer-a, consumer-a success), Pub for keys `extra order-A` (producer-a2), Pub/SubAfter for `order-B` (producer-b, consumer-b failure), SubAfter for `order-A-suffix` (consumer-prefix failure). 2. Concatenate their `transData` into one trace message whose keys are the union of `transKey` (the SDK index). 3. Call `RocketMQMessageProvider.getMessageTraceByKey(instance, "order-A", "orders", null)` with `queryMessage` returning that message. On `a562601` the result has 6 nodes and 3 consumer groups (`consumer-a`, `consumer-b`, `consumer-prefix`). ## What Did You Expect to See? Three nodes for `order-A`: producer-a, producer-a2 (because `extra order-A` contains the token `order-A`), and consumer-a. Consumer status contains only `consumer-a`. `order-B` and `order-A-suffix` are absent. A message-id lookup of a message in the same body still returns only that message id, including a Recall context, which has no keys column. A key lookup cannot attribute Recall and omits it. ## What Did You See Instead? Six nodes. The `order-A` timeline includes producer-b, a failed consume by consumer-b, and a failed consume by consumer-prefix. ## Related work checked - #1017 and the message-id guard in `parseTraceBody` only run when `filterByMsgId` is true. - #2520 added the key lookup with that flag set to false. Its shared-key test only checks two contexts that both carry the queried key. - #1504 parses every context in the body. - #4746 only maps node status in the web client. - #4933 (open) remaps failed trace status text in this class and does not filter by key. Upstream `master` still uses `filterByMsgId=false` for the key path. A repository search for `KEY_SEPARATOR` in this repo returned no hits. -- 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]
