RockteMQ-AI commented on issue #4361: URL: https://github.com/apache/rocketmq-dashboard/issues/4361#issuecomment-5692838306
**Issue Evaluation** Category: `bug` | Status: **Confirmed** The reported issue has been verified against the current codebase on `rocketmq-studio` branch. **Root Cause:** `RocketMQMetadataProvider.enrichGroupLiveStats` initializes `totalLag` (primitive `long`) and `delaySeconds` (primitive `int`) to zero. When `examineConsumeStats` returns `null` (line 325), the offset table is empty (line 329), or an exception is caught (line 352), the method returns without updating these fields — leaving them at their zero defaults. The frontend `consumer.tsx:906` renders `totalLag` through `isLagAvailable()` which treats `0` as valid (`lag >= 0`), so a stats failure is indistinguishable from a healthy zero-lag group. **Impact:** Operators reading the consumer-group inventory can mistake an unavailable broker statistic for a healthy zero backlog. The `delaySeconds` column (`consumer.tsx:919`) has the same problem — `formatDelay(seconds ?? 0)` performs no availability check. **Severity:** Medium — read/diagnostic correctness; no data mutation or offset changes. **Verified paths:** - `RocketMQMetadataProvider.java:320-355` — zero-default + early-return pattern confirmed - `ConsumerGroupVO.java:46-47` — `totalLag` is `long`, `delaySeconds` is `int` (primitive zero) - `consumer.tsx:906-910` — `isLagAvailable(0)` returns `true` - `consumerLag.ts` — `UNKNOWN_LAG = -1` sentinel exists but is not used by the group enrichment path The proposed design in the issue body is sound. An automated fix proposal may be generated. Reply `/approve` to proceed with PR generation. --- *Automated evaluation by RockteMQ-AI* -- 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]
