Mail: Get rid of »Error loading the selected message«

[jancborchardt]

This error should not show ever. It just makes it seem like the mail app is unstable. Basically it’s better to not show the notification at all than to show it.

When that selected message can not be loaded, just skip to the next until one can be loaded.

[ChristophWurst]

Let me guess: you get that error when you open the mail app, it grabs the message list from cache and starts opening a message _before_ the current message list was fetched. As you deleted that message on another client (e.g. your phone), that message can not be found any more and the error pops up.

As discussed recently, I don't really see the benefit of caching the message list any more, as it leads to inconsistency issues easily, like the one described above. How about we remove that message list caching? We should rather fix the slow requests that refresh the message list instead of hacky workarounds on the client-side.

[zeugmatis]

Very commendable effort! :-) But I'd agree, it sounds like an unavoidable race condition.

All webmail client software seems to have this problem since http is a stateless protocol so cannot keep the imap connection open like desktop MUA's do. Especially on large mailboxes located remotely, it has to re-login over and over for every command and those RTT's add up.

For us the solution in these cases has been to install imapproxy on the webserver, then point the webmail to localhost for it's imap server (which is actually imapproxy, keeping connections open).

Imapproxy packages are available for pretty much every linux dist as it is maintained now by the squirrelmail project (it was originally written for that).

[ChristophWurst]

For us the solution in these cases has been to install imapproxy on the webserver, then point the webmail to localhost for it's imap server (which is actually imapproxy, keeping connections open).

@zeugmatis thanks for the tip, I didn't even know that something like that exists :see_no_evil:

I definitely have to try that too, as my shared hoster's IMAP performance is really bad (e.g. doesn't support the SEARCH capability, hence search queries are slow as hell)

[zeugmatis]

YMMV depending on what imap server is being run at the other end - I've seen no change ... to over 10x increase in performance. Can't hurt to try! 😄

I need to spin up a dev VM for nightly testing - will get this done next week.

[ChristophWurst]

imapproxy is really helpful and can be used easily with docker:

docker run -d -e SERVER_HOSTNAME=imap.yourserver.com -p 1143:143 --name imapproxy cheungpat/imapproxy

Unfortunately, it only works for IMAP servers that accept connections on port 143 (with STARTTLS), hence providers like GMail do not work.

[zeugmatis]

Maybe we could put that into the documentation - I'll look into doing that myself, once the dev VM is ready. Thanks @ChristophWurst @jancborchardt for being so responsive! I'll clean up my github profile next week too. 😄

[Quix0r]

Small side note to reproduce it (maybe other way also possible):

• Open mail app
• Open mail message
• open mail app in 2nd tabulator/window
• open same mail message and delete it (2nd window)
• try to open it in 1st window

[ChristophWurst]

Now that we sync folders more intelligently (we didn't remove deleted messages with the old impl), it should be a lot harder to reach that application state as inboxes are synced twice a minute.

As discussed recently, I don't really see the benefit of caching the message list any more, as it leads to inconsistency issues easily, like the one described above. How about we remove that message list caching? We should rather fix the slow requests that refresh the message list instead of hacky workarounds on the client-side.

Closing this ticket now as that's exactly what I've been working on the last few months.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and questions.