I think the issue is more generic than notifications and generally related to mailing with the async mail API, but I have reproduced it with notifications, so here are the steps:
- in the administration of the wiki, set an address in the field "bcc email addresses"
- have 2 users available, User A and User B
- setup notifications mails frequency to "realtime" for User B and have him activate Mentions notifications by email
- in a comment of a page, have User A mention User B
- after a while, user B receives an email about this mention (can be as long as 10 minutes or so)
- the email is also delivered in the Inbox of the address specified as Bcc .
In administration, in the emails status, there is no failure stored and no unsent status stored. A success status is stored for this email if the email configuration "discard success statuses" is set to "no".
In administration, in the emails status, there is an "unsent" status stored for the email that user B just received. The status stored is prepare_success:
(the destination column has 2 email addresses in there, anonymized: one is the address of User B, one is the Bcc address).
The issue with this prepare_success status is that all emails with this status are considered incorrectly sent and are resent on server restart or when the scheduler job is triggered (as per
XWIKI-13991 or XWIKI-17967). As far as I could investigate, how these duplicate emails are actually displayed in the Inbox of the receiver depends on the email server / client, as they are actually the exact same email sent multiple times, so the client may not show it as a new email.
If email success status is configured to not be discarded, 2 statuses will be stored for this email: one with prepare_success and the other with send_success:
(the destination column for both these lines has 2 email addresses in there, anonymized: one is the address of User B, one is the Bcc address).
As far as I could explore the behaviour of my instance before the upgrade to 13.4.x , this looks a lot like a regression, but I don't have enough information to fully mark it as such.