GNOME Bugzilla – Bug 705206
Stale "Retrieving message xxx" in preview panel
Last modified: 2013-08-13 10:08:40 UTC
Moving this from a downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=990571 Description of problem: If I quickly delete two (or more) email messages, by quickly pressing the delete key twice, evolution will then hang forever, just saying "retrieving message XXX" in the preview window. The only way to proceed is to click on some other message and then going back to the message that previously didn't load. The message will this time load. Version-Release number of selected component (if applicable): evolution-3.8.4-1.fc19.x86_64 evolution-data-server-3.8.4-1.fc19.x86_64 How reproducible: Every time Steps to Reproduce: 1. Press delete twice 2. The next unread message will not load
I do not think it downloads the message forever, it's rather a stale message in the preview panel (note the status bar doesn't mention the same operation). I noticed something similar when only reading mails, the message is not loaded (using IMAP+) and the preview pretends it being received.
I'm not sure whether I'll be able to properly describe what I found, but let's try: There are multiple issues involved: a) any error in imapx_parser_thread() results in gave up and disconnect, possibly killing all pending operations by cancel_all_jobs() b) reusing failure error in camel_service_connect() on pending operations is also wrong, but I do not know how to fix it, it's broken by design, from my point of view What happens here: I can reproduce also when moving quickly between IMAP+ messages (no need for a delete), with a quick enough move between messages which are not downloaded yet (any delay/slow reconnect helps here too). The imapx_parser_thread() disconnected the store on its end, just before the request of camel_folder_get_message() is invoked. When doing the move between messages quickly enough, the first camel_folder_get_message() call is still connecting the store, thus the second request has the connect piled into the pending connect calls, but the previous one was just cancelled, thus the connect fails and the G_IO_ERROR_CANCELLED is propagated to the both camel_folder_get_message() calls, even the second call was not really cancelled (its cancellable is not cancelled at all). This is where the inherit of connect request result fails. The connect request come from camel_folder_get_message_sync() itself, from folder_maybe_connect_sync(). The misbehaviour was partly introduced in this commit: https://git.gnome.org/browse/evolution-data-server/commit/?id=6e66ea07 while I believe the CamelService object is responsible for the connection, if needed. The imapx doesn't do that, while for example EWS does connect when it's necessary (aka the commit looks like a workaround for an imapx issue). On the other hand, moving the similar code deeper into imapx code will not solve b). From my point of view, the above commit should be reverted, and the code should be moved to the provider. The way how camel_service_connect/_disconnect works should be reconsidered.
At least part of the problem was client cancellations for operations such as get_message() were terminating the IMAP parser thread. The parser thread needs to complete an operation and continue even if the client is no longer interested in the outcome. Only an I/O error, parsing error, server hang up, or application shutdown should break the parser loop. Fixed for Evolution-Data-Server 3.9.90 and 3.8.5 in: https://git.gnome.org/browse/evolution-data-server/commit/?id=fab4ebc81305cddcb92776d23c2498d41e0ff0c6 https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-8&id=dbcfdfeb2d4126fcdfeb6443e1cb72ee3106e2e6
Just for a record, the change removed related part for bug #693101. Maybe it's not a problem, I do not know.