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 793476 - [IMAPx] Message download interleave when synchronizing for offline
[IMAPx] Message download interleave when synchronizing for offline
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.24.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2018-02-15 01:31 UTC by Jean-François Fortin Tam
Modified: 2018-02-20 10:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screenshot of the statusbar during download (21.44 KB, image/png)
2018-02-15 23:21 UTC, Jean-François Fortin Tam
Details
screenshot of the whole interface when the download threads finish (129.24 KB, image/png)
2018-02-15 23:22 UTC, Jean-François Fortin Tam
Details

Description Jean-François Fortin Tam 2018-02-15 01:31:01 UTC
This pretty much happens to me every day: when I receive a heavy email in my IMAPx inbox (GMail), with attachments weighting multiple megabytes (even 4 MB is enough), Evolution tries to download/cache the mail when it comes in... except that I immediately see the mail coming in and try to display it (by clicking it in the message list and letting it show in the preview pane).

The result, however, is typically an error message, where Evolution says it can't display the message... so I have to switch to another message and back to this one, and THEN it displays because it is now fully cached.

So... if trying to display an email, Evolution should first check if it's already busy downloading that email in some background thread, and if so wait for that to finish before trying to display it?
Comment 1 Milan Crha 2018-02-15 17:54:09 UTC
Thanks for a bug report. The 3.24 is pretty old in this regard, though I'd be surprised if 3.26 might work too much differently, because it is supposed to work just as you said: when there is an ongoing message download, wait for it to finish. Maybe except of the fix when the message download had been issues in a wrong selected folder (selected in the connection, thus on the server side). I do not have that bug handy.

Do you know the exact error message, please? It says important information about the issue being spotted.

Also, do you use server-side filtering or evolution filters? It makes a difference, because the filters can move the message away while another thread still works with it.

I tried to reproduce it here, by adding 4MB email to my Inbox, then deleting it from the local cache, then opening it in a separate window twice. The second is waiting for the finish of the first request, not erroring out. This is with the development version, after 3.27.90 release.

It seems it downloads the file twice, which is wrong, but not for the third time. I can investigate this subissue later, away from this bug report, because I do not want to steal it.
Comment 2 Jean-François Fortin Tam 2018-02-15 23:20:10 UTC
Alright, I went through the yakshaving of upgrading to Fedora 27 today _just_ so I could test this ;)

I'm now running Evolution 3.26.5 on F27 and the problem still occurs in exactly the same way. I sent myself an email with two 10-megabyte JPEG images and if you click to display it just when it arrives in the inbox (through IMAP IDLE), you will see two download threads in the status bar (will attach a screenshot), and once it's done downloading it will error out with the "I can't find yer tmp file" nonsense (see 2nd screenshot).

My GMail IMAP account is configured in Evolution to "Synchronize remote mail locally in all folders".
Comment 3 Jean-François Fortin Tam 2018-02-15 23:21:05 UTC
Created attachment 368390 [details]
screenshot of the statusbar during download
Comment 4 Jean-François Fortin Tam 2018-02-15 23:22:06 UTC
Created attachment 368391 [details]
screenshot of the whole interface when the download threads finish

These two errors show up without needing to click on anything to trigger them.
Comment 5 Milan Crha 2018-02-20 09:18:34 UTC
I see. The main problem here is that it downloads the message twice at the same time, which it truly should not.
Comment 6 Milan Crha 2018-02-20 10:39:27 UTC
Okay, so the problem was that the synchronization for offline had been downloading the message, while the UI wanted to download the message to, to show it in the message preview. While the simple GET_MESSAGE requests could pile up in a queue (to not interleave), the same message download within SYNC_MESSAGE job didn't cause the piling, thus caused the interleaving. While at it, I noticed that piled job didn't use the already downloaded message, thus the message could be downloaded as many times as many jobs to download the same message had been in the queue. That's clearly wrong, thus I fixed that as well.

Created commit 656a5834a in eds master (3.27.92+)