tju-yxq opened a new issue, #3049: URL: https://github.com/apache/rocketmq-dashboard/issues/3049
## Problem Native alert metric handling normalizes the metric inconsistently and, in the rule-test path, does not normalize it at all: - `AlertRuleController` converts the request DTO to `AlertRuleVO` without trimming the metric. - `NativeAlertRulePolicy` compares the untrimmed metric against native metric names, so a whitespace-padded native metric can bypass domain, instance, operator, scope, duration, and sample-count validation. - `NativeAlertRuleTestService` then filters samples with `rule.getMetric().equals(sample.metricKey())`, while `AlertRuleEvaluator` uses `rule.getMetric().trim().equals(...)`. A padded metric therefore tends to return zero samples after validation has already bypassed policy checks. - `AlertNotificationTemplate` and `AlertRuleSemanticFingerprint` also use the raw metric for percentage formatting and ratio normalization, so the same semantic rule can behave differently depending on invisible whitespace. Issue #2951 and open PR #2960 describe this general problem and propose normalizing inside the metric catalog. That is narrower than the actual surface: the catalog is only one of several callers, and the test path calls `NativeAlertRulePolicy` and the sample filter before/without relying on that catalog normalization. ## Expected behavior Normalize the metric once at the API boundary (`AlertRuleRequestDTO.toAlertRuleVO()`), so policy validation, catalog validation, test sample filtering, evaluation, notification rendering, semantic fingerprints, persistence, exports, and imports all see the same canonical key. Existing rules with padded metrics should also be normalized on update and transfer import rather than being silently preserved. This issue is filed as a broader boundary-normalization follow-up to #2951/#2960, not a request to take over that PR. -- 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]
