tju-yxq opened a new issue, #2661: URL: https://github.com/apache/rocketmq-dashboard/issues/2661
`NotificationOutboxService` can turn a notification that was already sent into another delivery attempt. The dispatcher marks a row as `SENDING` and then performs the SMTP or webhook call synchronously. The claim is not renewed while that call is in flight, so a slow SMTP transaction (or a deployment with multiple Studio replicas) can make the row look stale after the one-minute claim window. A second dispatcher can then claim the same row and send the alert again. There is a second state-machine gap in the same path: after the external call succeeds, the row is marked `DELIVERED` and the delivery audit record is written. If that audit insert fails, the surrounding `try` block treats the bookkeeping exception as a send failure and moves the row back to `RETRY_WAIT`. The next dispatcher retries a notification that has already reached its recipient. Expected behavior: - renew a claimed row while its delivery attempt is still running, with the renewal conditional on the current claim token; - stop changing the row when ownership is lost, rather than allowing a stale worker to overwrite a newer attempt; - never convert a successfully completed external send into a retry only because audit recording failed; - record delivery and retry timestamps from the actual completion/failure time. Please add regression coverage for a slow/in-flight claim being renewed and for an audit write failure after a successful send. The tests should keep the existing at-least-once retry behavior for genuine webhook/SMTP failures. -- 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]
