zmuxuny opened a new issue, #6629: URL: https://github.com/apache/rocketmq-dashboard/issues/6629
### 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 utility and real ConsumerPage component regressions in Vitest/jsdom. ### Connected RocketMQ Cluster Controlled consumer group fixture: consumeStatsAvailable=true, measured totalLag=10000, onlineInstances=1, consistent subscriptions, empty independently fetched queue progress. ### Build Toolchain Project npm lockfile; Vitest / React Testing Library. ### Describe the Bug Consumer health reports no backlog risk when the group API supplies a valid measured aggregate lag but queue-level progress is empty. The summary can correctly show 10000 queued messages while the health tab displays no consumer-group health risk and a perfect score. Aggregate and queue observations come from separate data paths and need not have identical coverage. ### Steps to Reproduce 1. Supply an online group with consumeStatsAvailable=true and totalLag=10000, consistent subscriptions and no unrelated health warnings. 2. Return an empty queue progress list. 3. Open ConsumerPage group Details, then the health-diagnostics tab. 4. Assert the existing high-group-lag warning/critical finding is displayed. Fail-before evidence: utility regressions at the existing 1000/10000 thresholds both fail; the real page regression fails because the high-backlog finding is missing. Existing four utility controls pass. ### What Did You Expect to See? Retain the existing backlog thresholds and scoring, but use valid positive aggregate evidence even if detailed queue observations are absent or partial. Emit only one high-group-lag finding when both sources report it; do not treat unavailable/invalid aggregate values as measurements. ### What Did You See Instead? progressIssues returns early for an empty queue list and evaluates HIGH_GROUP_LAG only from known queue subtotal. The measured aggregate backlog is ignored by the risk finding although shown in the summary. ### Additional Context Distinct from #6433 (unknown-total presentation, explicitly no threshold/scoring change), #5926 (unavailable consume stats) and #5564 (translation). This proposal does not change unknown-total display or infer missing queue values. Tests also cover partial queue data, larger independent queue evidence, unavailable aggregate data and duplicate-finding prevention. ### 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]
