Frun1na opened a new issue, #6819: URL: https://github.com/apache/rocketmq-dashboard/issues/6819
### 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 form state (reproduced by a unit test) browser: not applicable — reproduced by a unit test ### Connected RocketMQ Cluster RocketMQ version: not applicable — reproduced with a stubbed alert service in a unit test access mode: not applicable deployment: not applicable ### Describe the Bug The alert rule editor rewrites the threshold field whenever the condition (operator) select moves to Unavailable: `web/src/pages/ops/alerts.tsx:1239-1241` runs `form.setFieldValue('threshold', 0)`, and switching back to a comparison operator does not restore anything. A rule being created as `> 1` therefore ends up saved as `> 0` after the operator passes through Unavailable, which for an availability metric (values 0/1) fires on every available sample, while `< 0` never fires. The same zero survives through the second path into this state: the metric select resets the operator to `>` when a metric that does not support the condition is picked (`:1166-1170`) and leaves the rewritten 0 behind. The write is also unnecessary. While the operator is Unavailable the threshold input is not rendered, so the payload assembled by `form.validateFields()` does not carry a `threshold` key at all and the server stores 0 for the rule (`AlertRuleRequestDTO.threshold` is a primitive `double`). The line only mutated the form, never the request. Unavailable is a normal option of the condition select for the four availability metrics (`nameserver.availability`, `broker.availability`, `proxy.availability`, `cloud.instance.availability`, all present in the native metric catalog the editor lists for the selected instance); the option is enabled as soon as one of them is the selected metric. ### Steps to Reproduce The regression test reproduces it without a live cluster: `web/src/pages/ops/__tests__/AlertsPage.test.tsx`, "keeps the threshold the user typed when the operator toggles through Unavailable". 1. Open the page (Alerts) and click 新建规则. 2. Pick an instance and the metric `broker.availability`. 3. Set the condition to `>` and type `1` into 阈值. 4. Set the condition to 不可用 (Unavailable), then back to `>`. 5. Observe the 阈值 field: it holds `0`. Submitting creates the rule with `threshold: 0`. On `a92c2314` the field reads `0`; with the fix it still reads `1`. ### What Did You Expect to See? The condition select does not touch the threshold. Passing through Unavailable leaves the threshold the user typed in place, and a rule created as `> 1` is saved as `> 1`. A rule whose operator really is Unavailable keeps being saved without a threshold, i.e. the server stores 0 for it exactly as before. ### What Did You See Instead? The 阈值 input shows `0` after the condition returns to a comparison, and the rule is submitted with `threshold: 0` — a value the user never typed, silently replacing theirs. ### 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]
