unbridled-41 opened a new pull request, #3997: URL: https://github.com/apache/rocketmq-dashboard/pull/3997
Related to #3996. ## Problem / Evidence The classic dashboard (previous generation in this repository, `master` branch) shows per-broker today/yesterday produce and consume counts on its cluster list, derived from the broker runtime stats (`frontend-new/src/pages/Cluster/cluster.jsx`: today/yesterday pro/cus count columns; source keys `msgPutTotalTodayMorning/Now`, `msgGetTotalTodayMorning/Now`, `msgPutTotalYesterdayMorning`, `msgGetTotalYesterdayMorning`). Studio's cluster topology fetches exactly the same `fetchBrokerRuntimeStats` KVTable per broker (`RocketMQClusterProvider.enrichBrokerWithRuntimeInfo`) but discards those counters — `web/src/pages/studio/BrokerCluster.tsx` only shows version, disk usage, and TPS in/out. Operators who want "how much does this broker carry per day / did traffic recover since yesterday" must fall back to Grafana or `mqadmin brokerStatus`. ## What was added - `BrokerVO` gains `putMessagesToday / putMessagesYesterday / getMessagesToday / getMessagesYesterday`, derived per broker from the runtime stats already fetched (today = now − today-morning; yesterday = today-morning − yesterday-morning; negative or malformed values fall back to the zero default, matching the dashboard provider's counter parsing convention). - The broker topology table renders the four counters as sortable columns (今日写入 / 昨日写入 / 今日消费 / 昨日消费), formatted like the TPS columns and nulled when `runtimeStatsAvailable` is false, consistent with the existing TPS/disk handling. - The broker CSV export gains the four columns. - i18n keys added for zh/en; no other tables touched. ## Priority & scoring FEATURE_PRIORITY = 项目需求 28 + 外部实现成熟度 24 + 项目契合度 17 + 可测试性 9 = **78**. Parent-project evidence (classic cluster list columns, cited above), zero-cost data availability (the runtime KVTable is already fetched), a natural home in the existing topology table, and deterministic parsing (testability). IMPLEMENTATION_CONFIDENCE: 85 — additive VO fields plus a pure parsing helper; no schema, API-contract, or provider-interface changes. ## Tests (actual commands and results) - `discoverClustersShouldParseDailyMessageCounters` (`RocketMQClusterProviderTest`): a runtime KVTable with the six counter keys yields today=600/yesterday=400 put and today=300/yesterday=400 get. - `discoverClustersShouldDefaultDailyMessageCountersWhenKeysAreMissing`: without the counter keys the four fields stay zero. - `renders daily message counters for each broker` (`BrokerCluster.test.tsx`): fixture counters render formatted in the broker table. - Red (implementation stashed, tests kept): server `mvn test-compile` → `invalid method reference: cannot find symbol` ×4 (`getPutMessagesToday` etc.); web `npx vitest run -t "daily message counters"` → `TestingLibraryElementError: Unable to find an element with the text: 1,234`. - Green: `mvn -ntp test -Dtest=RocketMQClusterProviderTest` → **17 passed**; `npx vitest run src/pages/studio/__tests__/BrokerCluster.test.tsx` → **16 passed (16)**. - Full backend `mvn -ntp clean test` → **2037 tests, 3 failures**, byte-identical to the pristine baseline (AuthCorsIntegrationTest ×2, AliyunInstanceProviderTest.getGroupProgressShouldMapLagRowsTest); 2037 = 2035 baseline + 2 new tests, zero new failures. - Full web `npx vitest run` → **923 tests, 2 failures**, both in the untouched `ConsumerPage.test.tsx` (the documented load-fragile file; that file passes 29/29 in isolation); 923 = 922 + 1 new test. - `npx tsc -b` clean; `eslint` clean on changed files; `npm run build` succeeds. ## Compatibility & Risk - Additive: optional fields on the web contract, new VO fields defaulted to 0, one pure parsing helper. No database, dependency, or API breaking change; licenses unchanged (only existing rocketmq types). - Counters are as accurate as the broker's own runtime counters (cumulative-since-morning semantics, reset at broker midnight) — the same semantics the classic dashboard displays, so no new accuracy risk is introduced. - The broker table grows by four columns; they render like the existing TPS columns and the table already scrolls horizontally. Cloud-provider brokers keep the zero defaults since the runtime-stat path is Apache-runtime scoped (gated by the existing `runtimeStatsAvailable` flag). -- 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]
