RockteMQ-AI commented on issue #2004: URL: https://github.com/apache/rocketmq-dashboard/issues/2004#issuecomment-5265866582
**Issue Evaluation** Category: `bug` | Status: **Confirmed** The reported race condition has been verified against the `rocketmq-studio` branch. **Root Cause:** `MybatisPlusAlertRepository.saveAlert()` implements an upsert pattern — it calls `selectById()` and falls through to `insert()` when the row is absent. In `AlertService.acknowledgeAlert()`, the flow is: 1. `findAlerts(null)` reads the alert from DB 2. Sets `acknowledged = true` in memory 3. Calls `saveAlert()` which re-checks by ID If `clearAcknowledged()` (which calls `alertMapper.delete(...)` for all acknowledged alerts) runs between step 1 and step 3, the alert row is deleted. Then `saveAlert()` finds no row by ID and **inserts** it back — resurrecting the cleared alert. The audit log records a successful acknowledgement for a record that was intentionally removed. **Impact:** Alert persistence integrity — acknowledged-and-cleared alerts can silently reappear, and the audit trail becomes inconsistent with actual DB state. **Severity:** Medium — requires concurrent acknowledgement and cleanup, but the window is real under load. **Suggested fix aligns with the issue description:** Replace the upsert in `acknowledgeAlert` with an update-only operation (e.g., `UPDATE ... WHERE id = ? AND ... ` returning affected-row count). If zero rows are affected, return 404 and skip the audit entry. --- *Automated evaluation by github-manager* -- 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]
