btlqql opened a new issue, #4297:
URL: https://github.com/apache/rocketmq-dashboard/issues/4297
## 1. Symptom
A native alert rule whose stored `instanceId` has surrounding whitespace
fires and keeps writing
`FIRING`/`ACKED` rows, but reports no active state:
- `GET /api/cluster-alert-rules/runtime` and the system-alerts active view
omit a genuinely firing
alert, so the operator sees "no active alert" while incident rows keep
being produced;
- `NativeAlertProcessor.reconcileMissingActiveStates` never sees the state,
so it is never resolved
and the incident cannot be cleared.
## 2. Root cause
`server/src/main/java/org/apache/rocketmq/studio/ops/alert/MybatisPlusAlertStateRepository.java:106-108`
```java
.filter(rule ->
metricKeys.contains(StringUtils.trimWhitespace(rule.getMetric())))
.filter(rule -> !StringUtils.hasText(rule.getInstanceId())
|| scope.instanceId().equals(rule.getInstanceId()))
```
The metric on the line above is trimmed, the instance id is not. The
identical filter in
`NativeAlertProcessor.reconcileMissingActiveStates` (`:101-103`) has the
same shape, so the rule is
dropped from the reconcile candidate list as well.
Everything that decides whether a rule fires trims instead:
- `NativeAlertRuleScopeMatcher.java:28-29` -
`rule.getInstanceId().trim().equals(sample.instanceId())`
- `NativeAlertMetricCatalogService.java:54` -
`findByIdentifier(instanceId.trim())` (so validation of
a padded id passes)
- `NativeAlertRuleTestService.java:94-96` - normalises the instance id
before matching
`AlertRuleRequestDTO.toAlertRuleVO()` copies `instanceId` untrimmed and
`MybatisPlusAlertRepository.toRuleEntity()` persists it verbatim, so a
stored `" inst-1 "` is
reachable through `POST /api/cluster-alert-rules/create`.
## 3. Impact
- A rule can fire while its active state is invisible, so the alert appears
to vanish between
notifications and its FIRING/ACKED row is never resolved.
- The padding is invisible in the API response, so the state cannot be
explained from the UI.
## 4. Reproduction
1. Create a cluster alert rule with `instanceId` padded, e.g.
`{"instanceId": " local ", ...}`
(it is accepted and stored verbatim).
2. Let the rule fire.
3. `GET /api/cluster-alert-rules/runtime` reports no active state for that
rule, while
`rmq_alert_state` holds a FIRING row for it.
## 5. Expected behaviour
- The instance selector is normalised exactly like the metric selector on
the line above, in both the
state lookup and the reconcile candidate filter, so a padded stored value
matches the collection
scope.
- Nothing changes for rules without padding.
--
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]
