RockteMQ-AI commented on issue #4326: URL: https://github.com/apache/rocketmq-dashboard/issues/4326#issuecomment-5679857686
## 🔍 Issue Analysis (Automated) Thank you for reporting this issue. **Classification:** Bug ✅ (Verified against codebase) **Assessment:** Confirmed real bug. Both `updateRule` (AlertService.java:206) and `toggleRule` (AlertService.java:271,283) unconditionally call `alertStateRepository.deleteByRuleId(id)`, wiping FIRING/ACK/PENDING state for every edit — including cosmetic ones like name, description, severity, or enable/disable toggles. The fix infrastructure already exists: `AlertRuleSemanticFingerprint` correctly distinguishes evaluation-identity fields (metric, threshold, operator, duration, scope) from cosmetic fields (name, description, enabled, severity, channels). The fingerprint is even persisted in `rmq_alert_rule.semantic_fingerprint`, but no code compares old-vs-new before deciding to wipe state. The fix is straightforward: (1) in `updateRule`, compare the stored fingerprint against the new one and only `deleteByRuleId` if they differ; (2) in `toggleRule` and `bulkToggleRules`, skip `deleteByRuleId` entirely since `enabled` is not part of the fingerprint; (3) update the existing tests (e.g., `updatingRuleShouldResetItsPreviousEvaluationStateTest`) to cover both the cosmetic-edit-preserved-state and semantic-change-clears-state paths. This issue has been verified as a genuine bug. We are looking into it. --- *🤖 Automated analysis by github-manager. A fix PR may be generated after further review.* -- 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]
