unbridled-41 opened a new issue, #5901: URL: https://github.com/apache/rocketmq-dashboard/issues/5901
### Studio Version branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is based on it) deployed as: not required to reproduce ### Runtime Environment Reproduced with the frontend tests (`cd web && npx vitest run src/pages/instance/__tests__/ConsumerPage.test.tsx`); any browser. ### Connected RocketMQ Cluster Any cluster with a 5.0 gRPC/proxy consumer group: the backend reports `onlineInstances = -1` and `totalLag = -1` for groups whose connection set or lag cannot be resolved (`RocketMQMetadataProvider.resolveConsumerConnection`). ### Describe the Bug The 总堆积量 and 在线客户端 columns of the consumer-group table sort with a one-sided key: ```ts // web/src/pages/instance/consumer.tsx sorter: (a, b) => lagSortValue(a.totalLag) - lagSortValue(b.totalLag), sorter: (a, b) => onlineInstancesSortValue(a.onlineInstances) - onlineInstancesSortValue(b.onlineInstances), // web/src/utils/consumerLag.ts export const lagSortValue = (lag) => (isLagAvailable(lag) ? lag : Number.MAX_SAFE_INTEGER); ``` Ant Design computes a descending column by negating the comparator's result (`antd/es/table/hooks/useSorter`: `sortOrder === ASCEND ? result : -result`), so the largest sentinel becomes the smallest value once the direction flips. Clicking 总堆积量 twice therefore lists the 不可用 groups *above* the real largest backlog, and the same happens to 在线客户端 for groups whose connection inventory is unavailable. The instance page solved exactly this with a direction-aware comparator (`compareResourceCounts`, "Ant Design reverses the comparator for descending order, so invert this branch to keep unavailable counts after numeric values in either order", pinned by `InstancePage.test.tsx`). The consumer page's two existing tests click each header only once, which is why the descending order was never covered. ### Steps to Reproduce 1. Open the consumer-group page of an instance with at least one group whose lag or connection inventory is unavailable. 2. Click 总堆积量 (ascending) and then again (descending). 3. In the descending order the 不可用 row is listed first. ### What Did You Expect to See? Rows without a measurement stay after the measured ones in both directions, as the instance table already does. ### What Did You See Instead? The unmeasured rows lead the descending list. Before the fix: `expected [ 'known', 'unknown' ] to deeply equal [ 'known', 'unknown' ]` -> received `[ 'unknown', 'known' ]`. ### Evidence - `web/src/pages/instance/consumer.tsx` (the two sorters), `web/src/utils/consumerLag.ts` / `consumerConnections.ts` (the sort keys), `web/src/pages/instance/index.tsx:98-114` (the precedent). - `cd web && npx vitest run src/pages/instance/__tests__/ConsumerPage.test.tsx -t 'descending'` - the new case fails before the fix and passes after it. ### Impact On the page used to triage consumer health, the ordering that should surface the biggest backlog/connection counts pushes the rows without any measurement to the top, which reads as "these are the worst". ### Acceptance Criteria - Both columns keep unavailable rows after measured ones in ascending and descending order, with unit tests for both directions and a page-level regression test. **Corresponding PR:** #ISSUEPR# -- 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]
