pilichoumao opened a new issue, #6423: URL: https://github.com/apache/rocketmq-dashboard/issues/6423
### Describe the bug At rocketmq-studio 779b8c0e7aed2396d3cc72743dcd544ea48e9ae6, the Consumer Group health diagnosis substitutes the sum of available queue lags whenever the group's totalLag is unknown (-1). For queue lags [17, -1], the page shows both the useful known subtotal 17 and a reported total 17, although the whole total is unavailable. Entirely unknown or absent queue observations become a reported zero. RocketMQAdminClientImpl deliberately reports totalLag=-1 when at least one queue has unknown lag. The diagnostic utility loses that distinction. Related #5926 addresses consumeStatsAvailable=false placeholder zeros, but its actual patch still substitutes partial queue subtotals when totalLag=-1. #5564 translates diagnostic messages. ### Expected behavior and evidence Keep the known subtotal, preserve independently measured aggregate totals (including zero), and use a queue-derived fallback only for a nonempty set whose lags are all available. Partial/all-unknown/no observations should keep reportedLag unavailable. An observed positive subtotal must still support the existing no-active-clients-with-lag warning. Research against the exact baseline gives 5 failing assertions / 61 passing tests across the diagnostic and ConsumerPage files; a temporary prototype passes 66/66, and a combination with #5926's actual patch and tests passes 68/68. The page services use provider-shaped fixtures; no live Broker test is claimed. This is a frontend diagnostic correction, not a change to collection, lag thresholds or permissions. -- 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]
