E-Mail sending iteration stops after first failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Confirmed
|
Low
|
OpenERP R&D Addons Team 1 |
Bug Description
1) Steps to reproduce the issue you have observed
A project issue with multiple followers exist. Add a message ("send message") to the project issue. The SMTP server does, however, not accept more than five emails in a row.
2) The result you observed
Multiple emails are sent, one per recipient (= followers minus the current user). If there is an exception, such as SMTPServerDisco
3) The result you expected
If there is a problem with sending an email, this should not affect other recipients. Also, if the SMTP server closed the connection at this point, further attempts to send out the email must be taken.
4) The platform you are using (and browser version, if relevant)
Debian, MTA is a Microsoft product, AFAIK.
5) The OpenERP version you are using
7.0-
Firstly, the feedback to your related bug reports (bug 1255611 and bug 1255615) is relevant here.
Secondly, this bug report is correct in the sense that when sending out a multi-recipient mail_mail, the mail_mail.send() method does not keep track of which of the recipients have successfully been sent an email.
In the presence of an outgoing SMTP server that does not reliably accept outgoing messages, this means that all recipients are considered failed at once, with 2 consequences: Technical/ Emails/ Emails) , all the recipients will be delivered again, possibly leading to duplicate messages *and* probably triggering the throttle limit again, making no further progress in the delivery.
- by default the recipients that have not yet received the email will never receive it unless a manual action is taken
- if a manual retry of the failed delivery is attempted by the system administrator (via /Settings/
So, in case of partial delivery failure the system could keep track of recipients who have already been delivered, and only retry the remaining ones. This does not solve the problem of handling the automated retry though.
However once we are able to partially retry a failed mail, we could imagine to distinguish permanent (5xx) and temporary (4xx) delivery failures, and automatically retry the temporary ones.
Note that this is considered a "nice-to-have" improvement rather than a bug, but mail delivery is sufficiently important to qualify it as a Low priority bug rather than a wishlist.
Thanks for your detailed bug report!