pilichoumao opened a new issue, #6311: URL: https://github.com/apache/rocketmq-dashboard/issues/6311
### Bug An in-flight native alert evaluation can recreate runtime state, emit a FIRING event and enqueue notification work after a rule-disable transaction has committed. The rule stays disabled, so subsequent normal collection cannot reconcile the recreated active state. ### Controlled reproduction on unchanged code On `rocketmq-studio@5e4c39b053c35a5598cc79ff331b8a54e649d7b1`, a Spring integration test uses the real NativeAlertProcessor, evaluation service, MyBatis repositories, state machine and notification outbox. Only the metric aggregation read is mocked to pause the evaluation with latches. 1. The processor reads an enabled rule and starts its independent evaluation transaction. 2. Pause at the aggregation read. On a different database connection, call the real `toggleRule(BUSINESS, id, false)` and commit. Verify disabled=true and zero state rows. 3. Resume the old evaluation. The stored rule remains disabled, but it creates one FIRING state, one FIRING event and one outbox row. The regression's zero-state/event/outbox expectations all fail. This has now reproduced on both H2 (MySQL mode) and an isolated MySQL 8 database, with different connection IDs for the two transactions. No real notification or external metric service is called. ### Proposed scope Before native lifecycle writes, perform a current locking read of the rule inside the same database transaction, rejecting deleted/disabled rules or changed evaluation semantics. Retain the row lock until state, event and outbox writes commit so concurrent management updates/deletes cannot finish first and then be undone. Cover both sampled evaluations and missing-state reconciliation, preserve presentation-only edits, rollback and existing state transition behavior, and verify both transaction orders with two connections. Related merged #5546 implements serial rule-change state cleanup. Open #5879 adds transactions to repository multi-write methods. Neither prevents this interleaving, which already reproduces across two real transactions. This proposal does not add a JVM-only lock or remove historical events/queued notifications to hide stale writes. -- 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]
