RockteMQ-AI commented on issue #2952:
URL: 
https://github.com/apache/rocketmq-dashboard/issues/2952#issuecomment-5502842327

   **Issue Evaluation**
   
   Category: `bug` | Status: **Confirmed**
   
   The reported issue has been verified against the codebase on the 
`pr-2533-review` branch.
   
   **Root Cause:** `AlertStateKey` requires a non-null, non-blank `fingerprint` 
(enforced in its compact constructor). In `AlertService.acknowledgeAlert()` 
(line ~441), the code checks `hasText(alert.getFingerprint())` before creating 
an `AlertStateKey`. For legacy FIRING rows that have no fingerprint (the column 
is nullable after the schema migration), the state acknowledgement is silently 
skipped. This means a legacy FIRING row and its later RESOLVED row cannot be 
correlated — the old FIRING row remains active in the correlation window and 
can suppress notifications for an already-resolved incident.
   
   **Impact:** Stale FIRING alerts without fingerprints continue to suppress 
notifications even after the underlying incident is resolved.
   
   **Severity:** medium
   
   **Suggested Fix:** Introduce a stable fallback identity for legacy rows 
derived from their rule ID and resource scope (e.g. `ruleId + domain + 
instanceId`). Use this fallback when fingerprint is absent, while preserving 
fingerprint-based correlation for new rows. Add a regression test covering a 
legacy FIRING/RESOLVED pair without fingerprints.
   
   An automated fix proposal can be generated. Reply `/approve` to proceed with 
PR generation.
   
   ---
   *Automated evaluation by RockteMQ-AI*


-- 
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]

Reply via email to