Frun1na opened a new issue, #6830: URL: https://github.com/apache/rocketmq-dashboard/issues/6830
### 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: a92c2314 (reproduced by a unit test against that commit) deployed as: built from source ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web console (reproduced with a stubbed consumer service) browser: not applicable — reproduced by a unit test ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed provider in a unit test access mode: the failing capture is the one the console documents for clients connected through a Proxy deployment: not applicable ### Describe the Bug The consumer client thread-stack modal renders its header row with `selectedStack?.threadCount ?? 0` (`web/src/pages/instance/consumer.tsx:2317`). `selectedStack` is null in the two states the modal can be in before a capture returns: while the request is in flight, and after it failed (`openStackModal` only records the failure in `stackError`, `:796-821`). In both, the row therefore presents **线程数 0** as if zero threads had been counted, although nothing was read: `threadCount` only exists on a response (`web/src/api/metadata.ts:137` is required, and the server always fills it with `threads.size()`, `RocketMQConsumerDiagnosticsProvider.java:113`). The capture-time item in the same block already answers a missing value with `-` (`:2314-2316`), so the header contradicts itself. The failure path does show the "this client's stack cannot be collected" alert, but it sits next to a `0` that reads as a measurement. ### Steps to Reproduce The regression test reproduces it without a live cluster: `web/src/pages/instance/__tests__/ConsumerPage.test.tsx`, "does not report a thread count for a stack capture that never returned". It stubs `listConsumerGroupPage` with one online client and `getConsumerStack` with a rejection, opens 详情 → 线程栈, and reads the `线程数` value cell: 1. On `a92c2314` the cell contains `0`. 2. With the fix it contains `-`. On a real deployment: open a consumer group whose clients connect through a Proxy, then use the 线程栈 action — the modal reports "线程数 0" next to the explanation that the capture is unsupported. ### What Did You Expect to See? The thread count shows that it is unavailable (`-`), matching the capture time beside it and the count we changed in #6144 ("stop presenting unread or partial values as measured"), instead of claiming zero threads were counted. ### What Did You See Instead? `线程数 0` — the modal states a count for a capture that never returned, both while the request is running and after it failed. ### Additional Context 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]
