After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705206 - Stale "Retrieving message xxx" in preview panel
Stale "Retrieving message xxx" in preview panel
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-07-31 15:26 UTC by Milan Crha
Modified: 2013-08-13 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2013-07-31 15:26:37 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
Comment 1 Milan Crha 2013-07-31 15:27:23 UTC
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.
Comment 2 Milan Crha 2013-08-01 08:38:07 UTC
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.
Comment 3 Matthew Barnes 2013-08-02 15:00:36 UTC
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
Comment 4 Milan Crha 2013-08-07 12:13:25 UTC
Just for a record, the change removed related part for bug #693101. Maybe it's not a problem, I do not know.