Frun1na opened a new issue, #6140: URL: https://github.com/apache/rocketmq-dashboard/issues/6140
### 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 (the affected code is the web client) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is in the web client's table sorting browser: not applicable — reproduced in a jsdom unit test (vitest + Testing Library) ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed cluster list in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug The broker/cluster page's two TPS columns sort a broker whose runtime stats could not be read as the lowest TPS. `web/src/pages/studio/BrokerCluster.tsx:379` (and the same for `tpsOut` at `:388`, base `5e4c39b0`): ```ts sorter: (a: BrokerRecord, b: BrokerRecord) => (a.tpsIn ?? -1) - (b.tpsIn ?? -1), ``` `tpsIn`/`tpsOut` are `number | null` — a broker whose runtime stats are unavailable keeps `null` and the cell renders `-` — so the `?? -1` key makes those rows the smallest value, and an ascending sort leads with rows that have no measurement at all. The codebase's own convention is the opposite: `utils/consumerConnections.onlineInstancesSortValue` and `utils/consumerLag.lagSortValue` keep an unavailable value after every known one in both sort directions (that is what #5902 fixes for the consumer page's two columns). ### Steps to Reproduce Reproduced by a unit test rather than against a cluster: 1. Render the page with one broker whose `runtimeStatsAvailable` is `false` (its TPS cells render `-`) and one broker with a measured TPS. 2. Click the "入站 TPS" column header to sort ascending. 3. The broker without a measurement is listed first, as if its TPS were the lowest. ### What Did You Expect to See? The rows without a measurement after the measured ones, in both sort directions, like the consumer page's lag and connection columns. ### What Did You See Instead? An unmeasurable TPS presented as the lowest TPS. ### Additional Context - A fix with a regression test follows in a pull request. - The case is pinned by a unit test that fails on `5e4c39b0` (`AssertionError: expected 1 to be greater than 2`). ### 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]
