youngkermit8-coder opened a new issue, #6964: URL: https://github.com/apache/rocketmq-dashboard/issues/6964
### Search before asking Searched open issues and PRs for notification lease/claim loss and preparation. Merged #2670 by @tju-yxq introduced in-flight renewal, claimant-bound bookkeeping and audit isolation; this report concerns a later admission boundary, not a replacement for that work. ### Environment `rocketmq-studio@c34535db0819d02f68e50a856cb3d2614f0dc5dd`, Java 21. ### Problem and reproduction `NotificationOutboxService.send` checks the heartbeat immediately after creating it, then loads the alert, silence state and general settings. Email sender resolution and channel-specific preparation also happen before the external call. Ownership is checked again only after that call completes. A deterministic reproduction holds one preparation operation with a latch, runs the actual registered renewal callback so `renewClaim` reports that the current token is no longer recognized, and then releases preparation. The old dispatcher still calls `JavaMailSender.send` or `RestTemplate.postForEntity`, even though loss was already known before the send started. A replacement claimant can therefore face an avoidable extra send from the old worker. The regression covers alert/silence/settings preparation for email, DingTalk and SMS, plus email sender resolution. Each loss case has a healthy-renewal control. On unchanged production source: 20 executions, 10 assertion failures (one send instead of zero), 10 passing controls, zero errors/skips. ### Proposed bounded change Check the existing in-memory heartbeat at the final SMTP/HTTP admission point, after preparation. Distinguish “not sent because ownership was lost” from external success, and leave claimant-bound recovery intact. Preserve explicit test notifications, genuine failure retries and the existing in-flight-loss behavior. This is cooperative admission, **not atomic database-to-network fencing or exactly-once delivery**. A lease can change immediately after the check, and already-started requests may complete. Receivers still need at-least-once deduplication. No API/schema/dependency/lease-policy change is proposed. ### Verification and limits A private three-file prototype passes five related suites / 79 executions, two further repetitions of all 20 new cases, Checkstyle and normal Windows production packaging. The existing material gate passes with its three pre-existing warnings retained. An independent unfiltered Linux backend run against a dedicated disposable MySQL is currently running; its result is not yet claimed. The dispatch worker and renewal callback are real; the timer, persistence and SMTP/HTTP boundaries in these targeted tests are controlled substitutes. No real notification, production frequency, actual JDBC claim-loss event or contest score is asserted. Prepared with AI assistance; the scope and observed results are stated explicitly. I intend to submit only this focused fix for 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]
