zmuxuny opened a new issue, #6181: URL: https://github.com/apache/rocketmq-dashboard/issues/6181
### 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@5e4c39b0, verified 2026-10-10. ### Runtime Environment Existing mocked provider with real ApacheRocketMqBusinessMetricsCollector and NativeAlertProcessor. Synthetic fixtures; no live broker, alert recipient or user account was changed. ### Connected RocketMQ Cluster Apache provider represented by mocks; no live cluster needed for collector-to-processor regression. ### Build Toolchain _No response_ ### Describe the Bug This continues the defect and proposed fix from @yyqdbngt's #4675, closed by the inactivity bot on 2026-10-03 without merging. Credit for the original finding, unavailable-delay fix, and collector regression belongs to #4675. This report adds current-branch collector-to-alert-processor reproduction for FIRING and ACKED states; it does not claim an original discovery or production incident. ApacheRocketMqBusinessMetricsCollector omits consumer.delay.seconds when consume stats are available but consumptionTimestampAvailable=false. Delay is unknown, not recovered. Because consumer delay belongs to the collector's declared scope, NativeAlertProcessor treats its absent fingerprint as a disappeared resource during successful-collection reconciliation. Existing FIRING or ACKED delay alerts become RESOLVED without measured recovery. ### Steps to Reproduce Use the existing mocked provider with a group that has available consume stats but no consumed-message timestamp. Collect metrics with real ApacheRocketMqBusinessMetricsCollector, then process the successful collection with real NativeAlertProcessor while the group's delay rule has an existing active state. Run focused collector/processor regressions against unchanged production source. Cases cover both FIRING and ACKED active states. ### What Did You Expect to See? Represent unmeasured delay as an explicit UNAVAILABLE sample with no fabricated numeric value and the same instance, cluster and consumer-group scope. Measured recovery should still clear an alert, and a genuinely disappeared group should retain established disappearance behavior. ### What Did You See Instead? On unchanged 5e4c39b0, 39 focused collector/processor tests execute: 36 pass and 3 fail as expected. The credited original collector regression finds no delay sample; two new lifecycle cases show FIRING and ACKED states both incorrectly become RESOLVED. ### Additional Context ### Prior work and duplicate check @yyqdbngt's #4675 was closed by inactivity without merging; its only review was an automated positive comment, with no maintainer rejection. Current open PRs and author/history searches found no replacement. Original finding, unavailable-delay fix and collector regression are credited to that contribution. #5920 concerns console zero-delay display and #6106 the AI tool projection. Neither changes metric collection/native alert reconciliation. ### Acceptance criteria - Missing consumption timestamp emits consumer.delay.seconds as UNAVAILABLE with no fabricated value. - Retain the group's cluster and identity labels. - FIRING and ACKED incidents are not resolved merely because timestamp is unmeasured. - Measured recovery and unrelated metrics remain unchanged. - Retain credited original regression and add collector-to-processor lifecycle coverage on current branch. AI assistance was used for current-source analysis and integration-regression authoring. Reused contribution will preserve Apache-2.0 licensing and attribution. ### 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]
