Update after review of the proposed change, and the cases it does not cover.
Changes to the proposal:
In a cluster, each member resumes its own pending mails for all the wikis when the application is ready, instead of waiting for each wiki to be loaded (a member that never serves a subwiki, for example an instance dedicated to background tasks, still produces events for its users). Without cluster the resume is unchanged.
The pre-filtering checks before each batch whether the instance is still the cluster singleton node, and a pre-filtering requested while one is running is no longer dropped.
The queue of live mails checks and adds an event atomically, so the same event added at the same time by the resume and by the pre-filtering is queued once.
observation.remote.id is documented as having to stay the same across restarts.
Cases not covered (documented limits):
Remote observation enabled on a single instance behaves as a cluster: only the mails of its own identifier are resumed, so if the identifier changes (permanent directory lost and no configured observation.remote.id) the pending mails of the previous run are not sent, where they used to be sent again.
More generally, the pending mails of a member whose identifier never comes back (member removed, or identifier changed at each restart) are no longer sent by anyone. Letting the cluster singleton node pick them up after a delay, so that a restarting member is not robbed of its own mails, is a possible follow-up.
The cluster singleton node is elected without regard to notifications.enabled or notifications.emails.enabled: if the singleton node disables them, the events without remote observation identifier are neither pre-filtered nor resumed.
When the events store is not shared by the members (embedded Solr in a cluster, each member records only its own events), the events without remote observation identifier stored by a member which is not the singleton node are not handled. Such events are in practice events stored before 14.1, pre-filtered long ago, so the impact should be close to zero.
Remaining duplicate window for the events without remote observation identifier only: when the singleton role moves between two running members, the former singleton node still sends the mails already in its queue while the new one resumes the same events; and an event resumed between its dispatch and the preparation of its mail is sent twice.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
