lizhimins commented on PR #4135: URL: https://github.com/apache/rocketmq-dashboard/pull/4135#issuecomment-5602088102
Closed as folded into #4115, merged into `rocketmq-studio` as 206314b9. Your conclusion was the correct one and it is the reason this is worth calling out: the test was wrong, the production code was right. `AliyunConverters.toQueueProgressRows` has only emitted the `broker="total"` aggregate as a fallback when there are no per-topic rows since #2907, but `getGroupProgressShouldMapLagRowsTest` still asserted two rows while stubbing both `topicLagMap` and `totalLag`. The decisive argument for keeping production behaviour is that `CloudRocketMqBusinessMetricsCollector` sums `getDiffTotal()` across every row it is handed, so emitting the aggregate alongside per-topic rows would have double-reported lag into Prometheus. This was one of three standing backend red lights on the branch, and it is now cleared — `AliyunInstanceProviderTest` runs 29 green. Your added fallback-only case is what pins the contract going forward, so the drift cannot silently come back. Nothing further needed from you — thank you for the fix. For context on why these were grouped: the AI resource tool chain had four independent defects (argument-slot routing, output-schema nullability, cloud topic type/perm, cloud consumer-group subscription mode) and merging any single one of them would not have made `rmq.topic.list` or `rmq.group.list` usable, so they were integrated as one change on the target PR's branch, each kept as its own commit with you as the author. -- 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]
