Frun1na opened a new issue, #6542: URL: https://github.com/apache/rocketmq-dashboard/issues/6542
### 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: `779b8c0e` deployed as: reproduced by a component 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 alert-rule page in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug Sorting the alert rules by "Last Triggered" ranks a rule that never fired as the oldest one (`web/src/pages/ops/alerts.tsx:706`): ```tsx title: t('alerts.lastTriggered'), width: 150, sorter: (a, b) => (a.lastTriggered ?? '').localeCompare(b.lastTriggered ?? ''), ``` `AlertRule.lastTriggered` is null for a rule that never fired, and the column says so — it renders `t('alerts.neverTriggered')` ("从未触发") for those rows. The empty-string substitute orders before every real timestamp, so an ascending sort puts every never-triggered rule first, as if those rules had fired before the rules that carry a stamp; a reader using the column to find what fired recently has to walk past rows that never fired at all. ### Steps to Reproduce Reproduced by a component test rather than against a cluster: 1. Render the alerts page with two rules: one with `lastTriggered: null` (the column shows 从未触发) and one with a stamp. 2. Click the "最近触发" header (ascending). 3. The never-triggered rule is listed first, before the stamped one. ### What Did You Expect to See? A rule without a stamp should stay out of the comparison's extreme positions, the way an unmeasured TPS is kept out of it on the broker cluster page; sorting ascending or descending should list it after the rules that actually carry a trigger time. ### What Did You See Instead? The never-triggered rule sorts as the earliest trigger and appears first. ### Additional Context - A fix with a regression test follows in a pull request. - The case is pinned by a unit test that fails without the fix: `AssertionError: expected 1 to be greater than 2` (the never-triggered row at index 1, the stamped row at index 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]
