tju-yxq opened a new issue, #2690: URL: https://github.com/apache/rocketmq-dashboard/issues/2690
Native alert collection persists a batch of metric samples and then evaluates every matching rule in one `NativeAlertProcessor.process(...)` call. That method is transactional, and the nested sample/rule loops do not isolate runtime failures. A failure while reading an aggregation window, updating rule state, saving an alert event, or enqueueing its notification therefore stops the loop immediately. Later rules and samples in the same collected batch are never evaluated. Because the exception escapes the transaction, database work completed earlier in the batch can also be rolled back. A deterministic regression test against the current `rocketmq-studio` head makes the first matching rule's snapshot lookup throw and provides a second healthy rule. The current implementation propagates the exception before the second rule can save state. Each matched rule/sample evaluation should have its own transaction boundary. A failed evaluation should roll back its state/event/outbox work, be logged without copying unbounded exception text, and allow the remaining evaluations to continue. Rule loading should still happen once per domain for a batch, and optimistic state-write conflicts should keep their existing no-event behavior. Please add coverage for continuation after an aggregation failure and for the per-evaluation transaction contract. -- 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]
