Frun1na opened a new issue, #6524: URL: https://github.com/apache/rocketmq-dashboard/issues/6524
### 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 unit test against that commit (the affected code is the backend service) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is the alert-metric capability list the rule editor and the rule validation read browser: not applicable — reproduced in a JUnit 5 service test ### Connected RocketMQ Cluster RocketMQ version: not applicable — the metric source is the collector's own vendor capability, asserted with a stubbed instance repository access mode: not applicable deployment: not applicable ### Describe the Bug `consumer.lag.max_queue` is offered for Aliyun and Tencent instances, but no cloud collector can measure it: - `NativeAlertMetricCatalogService.BUSINESS_CLOUD` (`server/src/main/java/org/apache/rocketmq/studio/ops/alert/NativeAlertMetricCatalogService.java:41-44`) lists it, that list is what `list(instanceId, BUSINESS)` returns for a cloud instance, and `validate(rule)` (`:78-85`) rejects only metrics that are absent from it. - #6184 changed `CloudRocketMqBusinessMetricsCollector` to publish that metric as `MetricAvailability.UNSUPPORTED` with reason `CLOUD_QUEUE_LAG_UNSUPPORTED`, because the Aliyun and Tencent progress rows are per-topic aggregates without queue offsets — the commit's own message records this as a maintainer follow-up: "`NativeAlertMetricCatalogService.java:41-44` still lists `consumer.lag.max_queue` under `BUSINESS_CLOUD`, so `validate()` keeps accepting cloud queue rules and the rule editor keeps offering a metric that can now only ever produce UNSUPPORTED — `docs/studio-native-alerting-design.md:147` requires the catalog to be capability-aware and hide unsupported metrics, and the metric table row at `:142` still names Aliyun and Tencent as sources." - `AlertRuleEvaluator.evaluate` (`:34-38`) treats an `UNSUPPORTED` sample as matched with the condition unmet, so a rule created through the editor can never fire. ### Steps to Reproduce 1. `GET /api/alert-rules/metrics?instanceId=<an Aliyun or Tencent instance>&domain=BUSINESS`: the response contains `consumer.lag.max_queue`. 2. `POST /api/alert-rules` with `{"instanceId":"<that instance>","domain":"BUSINESS","metric":"consumer.lag.max_queue","operator":">","threshold":50,...}` is accepted. 3. Without a running server, both are exercised from a unit test: `NativeAlertMetricCatalogServiceTest.doesNotOfferTheCloudQueueMaximumNoCloudCollectorMeasuresTest` drives `list(instanceId, BUSINESS)` and `validate(rule)` over a stubbed `InstanceRepository`. ### What Did You Expect to See? The cloud capability list without `consumer.lag.max_queue` — the only cloud metrics are `consumer.lag.total` and `topic.backlog.total` — and `validate` answering the existing `400` ("Native metric … is not supported by the selected Studio instance") for a cloud rule that names it. An Apache instance keeps offering and accepting the metric, because its collector derives the maximum from real per-queue offsets. ### What Did You See Instead? ``` Expecting actual: ["consumer.lag.total", "consumer.lag.max_queue", "topic.backlog.total"] to contain exactly (and in same order): ["consumer.lag.total", "topic.backlog.total"] but some elements were not expected: ["consumer.lag.max_queue"] ``` and `validate` returned normally instead of raising. ### Additional Context A fix with a regression test follows in a pull request. Already-stored cloud rules are deliberately not migrated; #6184's note leaves the fate of a frozen firing rule open. ### 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]
