unbridled-41 commented on PR #4247: URL: https://github.com/apache/rocketmq-dashboard/pull/4247#issuecomment-5696717498
@lizhimins Thanks for catching this — the column was indeed wired to the detail path only. Fixed in 17f5ed4e: - Traced the paginated inventory to `RocketMQMetadataProvider.listConsumerGroupsPage` → `enrichLiveStats`, which already issues a bounded per-row `examineConsumeStats` (page-size futures, 8 threads, 3s timeout) to fill `totalLag`/`delaySeconds` — it was just dropping `stats.getConsumeTps()`. The fix reports it there, so no new broker calls and no per-row N+1 beyond the enrichment that already existed; the CSV export reads the same rows, so both surfaces share one source. - Cloud providers are untouched and keep reporting 0, as before. - Regression: `listConsumerGroupsPageShouldSurfaceConsumeTpsFromConsumeStatsTest` calls `listConsumerGroupsPage` directly and asserts a non-zero TPS on the returned row — it fails against the detail-only wiring (red: `expected 123.5 but was 0.0`) and passes with the fix. - `RocketMQMetadataProviderTest` 44/44, `RocketMQAdminClientImplTest` 65/65, `MetadataServiceTest` 53/53; full backend suite shows only the 17 pre-existing Spring-context errors of the 9 integration classes (verified identical on pristine base). The branch was also rebased onto the current `rocketmq-studio`. Happy to re-review whenever you get a chance. -- 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]
