-
-
Notifications
You must be signed in to change notification settings - Fork 107
Description
Historically we ignore receive_imf errors, only writing errors in the log:
Lines 1469 to 1491 in 545643b
match receive_imf_inner( | |
context, | |
folder, | |
uidvalidity, | |
request_uid, | |
rfc724_mid, | |
body, | |
is_seen, | |
partial, | |
) | |
.await | |
{ | |
Ok(received_msg) => { | |
received_msgs_channel | |
.send((request_uid, received_msg)) | |
.await?; | |
} | |
Err(err) => { | |
warn!(context, "receive_imf error: {:#}.", err); | |
received_msgs_channel.send((request_uid, None)).await?; | |
} | |
}; | |
} |
If there is a problem inside receive_imf, e.g. during message processing, the message is simply skipped.
The idea behind this is to avoid getting stuck in infinite loop because we received some message that we cannot process.
The downside of this approach is that if there are such problematic messages, the messages are silently skipped and the problem is never fixed. For example there is this report of some messages not received and it is not clear whether there is a receive_imf problem:
https://support.delta.chat/t/e-mails-from-protonmail/4117
It is also very difficult to guide the user to look at the logs, in this case it did not happen and the problem is not resolved.
I think getting IMAP loop stuck is not worse than silently lost messages. The advantage is that we will have consistent error handling following https://github.com/chatmail/core/blob/main/STYLE.md everywhere and not have to think about whether the function we are in is below receive_imf or not to ignore "non-critical" errors: #7038 (comment)