Frun1na opened a new issue, #6139: URL: https://github.com/apache/rocketmq-dashboard/issues/6139
### 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 a unit test against that commit ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the LiteTopic session contract 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 provider in a unit test. The field is never assigned by any provider, so no live cluster changes the outcome. ### Describe the Bug The LiteTopic session drawer offers a **"Pop 进度 / Pop Progress"** panel that can never render, and the `rmq.litetopic.session` tool contract publishes a field nothing computes. `LiteTopicSessionVO.popProgress` (`LiteTopicSessionVO.java:43`) is declared and serialized, but no provider assigns it: the only write sites found anywhere are fixtures. The whole chain is dead: - `LiteTopicSession.popProgress` and its nested `PopConsumeProgress` shape (`model/LiteTopicSession.java:62, :80-88`) are never written by `RocketMQLiteTopicProvider` or any other provider — a repository-wide search finds declarations and reads only; - `LiteTopicSessionOutput.popProgress` (`ops/ai/tool/contract/litetopic/LiteTopicSessionOutput.java:43`) forwards it to `rmq.litetopic.session`, so the tool schema promises a counter the server never computes; - the web drawer renders the panel only when the value is non-null (`web/src/pages/studio/LiteTopic.tsx:732-742`), so it never appears on a real deployment; - the tests that "cover" it (`LiteTopicControllerTest.getSessionShouldReturnSession`, `LiteTopicSessionToolHandlerTest`, `LiteTopic.test.tsx`, `liteTopic.test.ts`) all build the value by hand, which is why the gap is invisible in the suite. ### Steps to Reproduce 1. Run the web case from the pull request below at `5e4c39b0` — the drawer renders a Pop-progress bar from the fixture's value: `cd web && npx vitest run src/pages/studio/__tests__/LiteTopic.test.tsx` 2. Or, against a live 5.x cluster with LiteTopic enabled: open `/litetopic`, pick a session and look for the 消费速率 panel — no Pop progress section is ever rendered, and `GET /api/liteTopic/session/{sessionId}` never contains `popProgress`. ### What Did You Expect to See? No panel — and no tool-schema field — for a metric no provider computes, or a panel backed by a value the broker actually reports. ### What Did You See Instead? A panel that can only appear in tests (`popProgress` is always absent), a `popProgress` component in the AI tool contract that is always omitted, and four tests that keep the dead path looking covered. ### Additional Context `#5600` removed the NameServer tab's fabricated "Connections" column for the same reason — the value was never produced and the field was dropped instead of being filled with a guess. A fix with a regression test 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]
