[PR] fix(group): mark cloud consumer-group lag unknown instead of zero [rocketmq-dashboard]

["zjncs (via GitHub)" <gi...@apache.org>]

zjncs opened a new pull request, #7267:
URL: https://github.com/apache/rocketmq-dashboard/pull/7267

   ## Problem
   
   `TencentInstanceProvider.toConsumerGroup` (`:1033-1049`) and `AliyunConverters.toConsumerGroupVO` (`:175-190`) never set `totalLag`/`delaySeconds` — and `ConsumerGroupVO` (`:39`, `:44`) declares them as primitives defaulting to `0`. So **every consumer group on an Aliyun or Tencent instance renders 总堆积量 "0" and 消费延迟 "0s"** in the group list, regardless of real backlog — while the same group's progress drawer shows the true number (`getGroupProgress`, which both clouds implement). An operator scanning the cloud group list sees a healthy "0 backlog" for a group with millions of accumulated messages.
   
   The Apache provider already solves this with the -1 unknown sentinel (`RocketMQAdminClientImpl.java:170-191`: "resolve to the unknown sentinel marks totalLag unknown instead of summing it away as zero lag"), and the web already renders -1 as 不可用 (`consumer.tsx:1024-1037`, `isLagAvailable`). Neither cloud provider uses either mechanism.
   
   ## Fix
   
   Both cloud converters set `totalLag` and `delaySeconds` to the existing `ConsumerLagResolver.UNKNOWN` sentinel (verified against the cloud SDKs: the list-response models expose no lag field, so the real value is genuinely unavailable on this path — the sentinel is the honest answer).
   
   ## Verification
   
   - `listConsumerGroupsShouldMarkLagAndDelayUnknownInsteadOfZeroTest` for both providers — RED first (`expected: -1L but was: 0L`), GREEN after.
   - `mvn -Dtest='TencentInstanceProviderTest,AliyunInstanceProviderTest,AliyunConvertersTest,AliyunConvertersLagTest,TencentCloudLagFailureScopeTest' test` → 156 pass. Java verification: `mvn -Dtest='<classes>' -Dspring.profiles.active=dev test` from `server/` with JDK 21 (the dev profile provides H2; a plain run needs MySQL, pre-existing).
   
   ## Risk / conflict disclosure
   
   None identified. Two sibling PRs of mine touch other converter methods of the same files (`toTopicConsumer` TPS availability, `toRecordVO` message size) — different methods; happy to rebase in merge order.


-- 
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: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org