coder999o opened a new issue, #6634: URL: https://github.com/apache/rocketmq-dashboard/issues/6634
## Description A business-key trace lookup can return stages from different Message IDs. The web diagnostics treat those stages as one message lifecycle, calculating end-to-end latency and stage gaps across unrelated messages. ## Reproduction On `rocketmq-studio` at `e2f815fb`, use a key result with these successful stages: | Message | Produce timestamp | Consume timestamp | Individual lifecycle | | --- | --- | --- | --- | | A | 10:00:00.000 | 10:00:00.010 | 10 ms | | B | 10:01:00.000 | 10:01:00.010 | 10 ms | Both messages share the lookup key. All nodes finish successfully and the returned consumer status is successful. `analyzeMessageTrace` reports a 60,010 ms end-to-end latency, emits `SLOW_END_TO_END_TRACE` and `SLOW_TRACE_GAP`, and grades the result critical. Sorting the stages does not fix the correlation problem. Interleaved stages can also produce a false timestamp-regression finding. ## Expected behavior Key results without per-node message identity should not claim one end-to-end lifecycle or inter-stage delay. Preserve individual timestamps, actual node costs, delivery failures and retry evidence. Message-ID lookups should retain their existing lifecycle diagnosis. The result's interpretation should follow the completed lookup rather than the editable input mode. ## Verification Deterministic frontend regressions reproduced the false critical grade for chronological and interleaved stages. The existing provider regression also demonstrates multiple messages in a key lookup. No live Broker query was run for this report. -- 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]
