Aias00 opened a new issue, #2004:
URL: https://github.com/apache/rocketmq-dashboard/issues/2004

   ### Before Creating the Issue
   
   - [x] I searched open issues and pull requests for the same backend 
persistence race.
   - [x] I confirmed the behavior on the latest `rocketmq-studio` branch.
   
   ### Description
   
   `AlertService.acknowledgeAlert` reads a system alert and then calls 
`AlertRepository.saveAlert`. The MyBatis repository implements `saveAlert` as 
an upsert: it selects by ID and inserts when the row is absent.
   
   If `clearAcknowledged` deletes the alert after the acknowledgement request 
reads it but before `saveAlert` runs, the acknowledgement path inserts the 
deleted alert again. The API reports success and records a successful 
acknowledgement audit, while a record intentionally removed by the cleanup 
operation is resurrected.
   
   This is separate from the frontend duplicate-request tracking in 
#1573/#1574; it is a backend persistence race between acknowledgement and 
cleanup.
   
   ### Expected behavior
   
   Acknowledging an existing alert should be an update-only operation:
   
   - never recreate an alert that was concurrently removed;
   - report a structured `404` when the update affects zero rows;
   - do not record a successful acknowledgement audit in that case.
   
   ### Suggested fix
   
   Expose an update-only repository operation that returns the affected-row 
outcome, use it in `acknowledgeAlert`, and retain insert/upsert behavior only 
for genuine alert creation paths if needed.
   
   ### Regression tests
   
   - repository update reports `false` when MyBatis updates zero rows and never 
inserts;
   - service maps the failed update to `404` and skips success audit;
   - normal acknowledgement still persists and audits successfully.
   
   ### Scope
   
   RocketMQ Studio Track 1: operational alert persistence integrity.
   


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