Frun1na opened a new issue, #6779: URL: https://github.com/apache/rocketmq-dashboard/issues/6779
### 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 deployed as: reproduced by a unit test against that commit ``` ### Runtime Environment ``` OS: Ubuntu on WSL2 (test host) MySQL: not applicable — the defect is in the request validation of the alert-rule DTO browser: not applicable — reproduced through the REST contract ``` ### Connected RocketMQ Cluster ``` not applicable — reproduced with the Jakarta Bean Validation validator over AlertRuleRequestDTO ``` ### Describe the Bug `AlertRuleRequestDTO` carries two duration fields that are parsed by the same `AlertRuleDuration`, and since #6451 they no longer validate the same syntax. `duration` was tightened to the Prometheus form (`PROMETHEUS_DURATION_REGEXP`, each unit at most once, descending), but `reminderInterval` still carries the pre-#6451 expression (`server/src/main/java/org/apache/rocketmq/studio/ops/alert/AlertRuleRequestDTO.java:63`): ```java @Pattern(regexp = "(?:[0-9]+(?:ms|s|m|h|d|w|y))+", message = "reminderInterval is invalid") ``` so `POST /api/alert-rules` (and its cluster twin `/api/cluster-alert-rules`) accepts an interval such as `1m1m`, `1s1m` or `1h2d`. `AlertRuleDuration.parse` only checks that the unit matches are adjacent; it sums the parts in the order it finds them, so a stored `1m1m` is a **two-minute** reminder and `1h2d` a 49-hour one, and the rules table renders the raw `1m1m` — a value the editor's own interval list (5m / 15m / 30m / 1h / 4h) does not offer, so the operator cannot tell what it means. ### Steps to Reproduce 1. `POST /api/alert-rules` with a body whose `reminderInterval` repeats or reorders a unit, e.g. `{"name": "High Lag", "metric": "consumer.lag.total", "operator": ">", "threshold": 1, "instanceId": "<instance>", "reminderInterval": "1m1m"}` — the request is accepted (no violation on the field), and the same body with `"duration": "1m1m"` is rejected with `duration is invalid`. 2. Observe that the stored interval is then used as the sum of its parts (`AlertStateMachine` schedules the next reminder at `lastNotifiedAt.plus(reminderInterval)`). ### What Did You Expect to See? `reminderInterval` rejects a repeated or reordered unit with the same 400 the `duration` field returns, because both are parsed by `AlertRuleDuration` and the console can only offer descending whole-unit values. ### What Did You See Instead? The request is accepted; a repeated unit is silently summed (`1m1m` = 2 minutes) and the stored string is what the rules table shows. ### Additional Context A fix with a regression test follows in a pull request: `reminderInterval` uses `PROMETHEUS_DURATION_REGEXP`, the constant `duration` already validates with. ### 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]
