zmuxuny opened a new issue, #7317: URL: https://github.com/apache/rocketmq-dashboard/issues/7317
### 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 Current source inspected on October 21, 2026: `rocketmq-studio@127c47b06a268cc74224d5f34c56ec7c36ac0d55`. The original controlled reproduction used `779b8c0e7aed2396d3cc72743dcd544ea48e9ae6`. ### Runtime Environment Linux, frontend utility tests and the real ConsumerPage component under Vitest/jsdom, with synthetic service responses. No live cluster or browser-visual result is claimed. ### Connected RocketMQ Cluster No live cluster is required. The fixture supplies an online group with `consumeStatsAvailable=true`, `totalLag=10000`, consistent subscriptions and an empty independently fetched queue-progress list. ### Build Toolchain Repository-pinned npm dependencies, Vitest and React Testing Library. Historical local verification used Node 24; GitHub CI uses Node 20. ### Describe the Bug This continues #6629, which github-actions[bot] [automatically closed after seven days without issue activity](https://github.com/apache/rocketmq-dashboard/issues/6629#issuecomment-6305425711) on October 21. That closure was inactivity housekeeping, not a maintainer rejection. Existing implementation PR #6654 remains open and Ready for review. No duplicate implementation PR is proposed. Consumer health can show a measured aggregate backlog in the summary while reporting no backlog risk and a perfect health score when queue observations are absent. The two observations come from independent data paths. The [current progressIssues implementation](https://github.com/apache/rocketmq-dashboard/blob/127c47b06a268cc74224d5f34c56ec7c36ac0d55/web/src/utils/consumerGroupDiagnostics.ts#L222-L242) still returns immediately for empty queue progress and evaluates the high-group-lag finding from the queue subtotal alone. ### Steps to Reproduce 1. Supply an online group with `consumeStatsAvailable=true`, `totalLag=10000`, consistent subscriptions and no unrelated warnings. 2. Return an empty queue-progress list. 3. Open ConsumerPage group Details, then the health-diagnostics tab. 4. Check the high-group-lag finding against the displayed aggregate backlog. The original fail-before verification reported failing utility cases at the existing 1000/10000 thresholds and a failing real-page case, with existing controls passing. Today's recheck was source inspection, not a new execution of those tests. ### What Did You Expect to See? Use valid measured aggregate backlog as independent evidence even when queue observations are absent or partial. Retain the existing thresholds and scoring, use the larger valid observation, and emit only one high-group-lag finding. Explicitly unavailable or invalid aggregate values must not be treated as measurements. ### What Did You See Instead? The aggregate backlog is omitted from the risk finding even though it can appear in the summary. ### Additional Context PR head: `d18e12a810385ee34b67da6fcc31eb7b1e91388a`. - [CI run 38545841541](https://github.com/apache/rocketmq-dashboard/actions/runs/38545841541) for that exact head remains successful, with all five jobs passed, rechecked on October 21. - Historical local validation and its limits remain in #6654: focused utility/page coverage and TypeScript/build checks passed; its dated full local frontend run had two unchanged CloudCredential test failures. That local result is not being relabeled as a full-suite pass. - No fresh local test run, live cluster, browser visual verification, or maintainer approval is claimed. The scope remains separate from #6433 (unknown-total presentation), #5926 (unavailable consume statistics) and #5564 (translation). It does not infer missing queue values or change unknown-total presentation. The original report and existing PR preserve the earlier evidence. AI assistance was used for this source/status recheck and tracking continuation. ### 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]
