Frun1na opened a new issue, #6109: URL: https://github.com/apache/rocketmq-dashboard/issues/6109
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: rocketmq-studio git commit id: 5e4c39b0 deployed as: reproduced by unit tests against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the LiteTopic session response and in the console rendering, not in persistence browser (for UI issues): not applicable — reproduced with jsdom in a vitest run ### Connected RocketMQ Cluster not applicable — reproduced with a stubbed broker admin client in a unit test. The cap is a fixed constant in the provider, so no live cluster changes the outcome; a real 5.x cluster only changes how many lite topics the session has. ### Describe the Bug The consumed-message count of a LiteTopic session is a **lower bound reported as a total** once the session has more lite topics than the scan reads. `RocketMQLiteTopicProvider.consumedMessages` sums the per-lite-topic consumer offsets from `getLiteGroupInfo`, but stops after `MAX_SESSION_LITE_TOPIC_SCAN` (200) lookups (`RocketMQLiteTopicProvider.java:86, :333-358`) and only logs `"LiteTopic session consumed-offset scan truncated at 200 lite topics"`. The session detail then publishes that partial sum as `consumedMessages`, derives `totalMessages = consumedMessages + pendingMessages` from it, and computes `consumptionRate` from the two (`buildSession`, `RocketMQLiteTopicProvider.java:307-312`). Consequences on a session with more than 200 lite topics: - the console drawer (`web/src/pages/studio/LiteTopic.tsx`) shows a 已消费消息 count that is too low, a 总消息数 that is too low, and a 消费进度 percentage that reads lower than the real progress — a busy session looks like it has unconsumed messages; - the `rmq.litetopic.session` tool reports the same numbers with no indication that they are partial; - nothing in the response, the log the user can see, or the UI distinguishes "counted" from "counted so far". The pending count is not affected: it comes from the group-level `getTotalLagCount`, which is not capped, so the two halves of `totalMessages` are also on different footings. ### Steps to Reproduce 1. Run the provider case added in the pull request below at `5e4c39b0`: `cd server && mvn -B -ntp test -Dtest=RocketMQLiteTopicProviderTest#getSessionShouldReportATruncatedConsumedScanTest` 2. Or, against a live deployment: open a LiteTopic session whose owning client has more than 200 lite topics (`/litetopic` → 查看会话) and compare 已消费消息 with the sum of the session's per-lite-topic consumer offsets; the console shows only the first 200. ### What Did You Expect to See? A session whose consumed count could only be computed from part of its lite topics should say so: the count is a lower bound rather than a total, and a percentage must not be derived from it. ### What Did You See Instead? `consumedMessages` and `totalMessages` are presented as measured totals, the drawer renders a 消费进度 percentage from them, and the AI tool output repeats the same values with no completeness signal. ### Additional Context The sibling scans in the same provider already disclose their caps to the caller where the shape allows it, and `#4927` added an explicit `truncated` channel for the capped DLQ scan. The session detail has no such channel today. A fix with regression tests follows in a pull request. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
