zmuxuny opened a new issue, #6627: URL: https://github.com/apache/rocketmq-dashboard/issues/6627
### 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 @ 779b8c0e7aed2396d3cc72743dcd544ea48e9ae6 ### Runtime Environment Linux x86_64; deterministic backend tests using real provider, native business collector and alert evaluator. ### Connected RocketMQ Cluster Apache RocketMQ provider with mocked consumption-offset responses; known broker/consumer offsets are equal and last consumed store timestamp is one hour old. ### Build Toolchain JDK 21, Maven 3.9.11. ### Describe the Bug A fully caught-up consumer with a valid but old last-consumed timestamp is reported as delayed merely because its topic has been idle. Both group detail and inventory derive delay from now minus that timestamp even when all offsets are known and totalLag is exactly zero. The native collector publishes this as an AVAILABLE consumer.delay.seconds measurement, allowing a false high-delay alert. ### Steps to Reproduce 1. Return fully known equal broker/consumer offsets, giving totalLag=0. Set a valid last consumed store timestamp about one hour in the past. 2. Read the real group detail and inventory mapping paths. 3. Pass the resulting provider data through the real native business collector and AlertRuleEvaluator with consumer.delay.seconds > 300. 4. Assert zero consumption delay and no alert. Nine new scenarios on unchanged production code: three target failures, six passing controls, no errors. Controls cover positive backlog, unknown lag and absent timestamp behavior in both paths. ### What Did You Expect to See? When complete offset evidence proves there is no backlog and timestamp data is available, consumption delay should be zero and should not fire a high-delay alert. Keep existing behavior for positive/unknown lag and unavailable timestamps. ### What Did You See Instead? The caught-up idle group reports roughly 3600 seconds of delay, and the native evaluator fires the >300-second rule. ### Additional Context This is distinct from #6187, which preserved unavailable delay when timestamps are absent. The regression keeps that unavailable-data behavior; it does not turn unknown delay into a measured zero. No live cluster incident is claimed: the fail-before tests exercise the actual Studio mapping, collector and rule evaluator with controlled broker responses. ### 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]
