GNOME Bugzilla – Bug 721286
imapx: read messages become unread when reopening Evolution
Last modified: 2014-11-03 18:07:45 UTC
I'm using a Gmail account set up with GNOME Online Accounts with the default send/receive options. Since upgrading to Evolution 3.10, messages which I have marked as read become unread the next time I open Evolution, unless I change views to a different folder before exiting Evolution. For example: 1) Open Evolution, visit a folder with unread messages 2) Mark all messages as read, either by viewing each of them individually or with the context menu when right clicking on the folder 3) Close Evolution 4) Reopen Evolution. The current view is set to the previously-visited folder, and all previously-read messages are now unread But if I add a new step (2a) switch to viewing a different folder, then when I reopen Evolution, the messages are properly marked as read. This feels exactly identical to Bug #685034, except this time I do not have IDLE enabled.
(In reply to comment #0) > The current view is set to the previously-visited folder, To be perfectly clear: the view when opening Evolution is always set to whatever folder I was looking at when I closed it, so that is as expected.
I have the same problem with Evoluton{,-Data-Server} 3.10.3; I do have IDLE enabled, though. Some more information: Sending/receiving mail (F12), refreshing the folder or emptying the trash before closing Evolution all cause the mails be marked correctly.
I can see several issues involved in flag syncing in imapx/camel, thus I confirm the bug.
Seems to be dupe of #710080
*** This bug has been marked as a duplicate of bug 710080 ***
Bug #721286 - IMAPx: read messages become unread when reopening Evolution Couple things changed here: a) the camel_folder_summary_get_changed() could return list of changed messages only if they were loaded in memory, which is not correct - I think it's part of the issue why it failed b) it could happen that imapx_server_sync_changes() was called to save some changes, but then didn't change anything; in such cases, messages marked as locally changed were never unmarked, which led to false tests; I added a function to unmark the messages as locally changed (this can cause slow close of evolution for the first time, due to unsetting of the flag, but later ends are fine) c) state of the message flags on the server is the master state, except of the state where locally stored info is marked as locally changed. This allows to show proper state of messages on the server (it is influenced by a) and b) too, so it might take up to two evolution starts to get the same view in evolution as is the state on the server) That is with evolution-data-server commit [1]. Then I realized the patch doesn't work for gnome-3-10 branch, thus I spent more time on it and added the second commit in eds master, which: d) do not use CamelOperation in the parser thread, because it can be cancelled at an application end with camel_operation_cancel_all() call, which is done too early, before any pending jobs are properly finished (it can be IDLE job, or save of folder changes back to the server) Finally a change at evolution itself was also done, there was no reason to call folder change synchronization at the end of the application from mail_shell_view_prepare_for_quit_cb, because the same (and a bit more) is done in mail_backend_prepare_for_quit_cb. The result of this in IMAPx was that the second call stopped immediately due to other "save folder changes" operation was pending in the job queue. And that's all I've found. Created commit c7ef1c9 in eds master (3.11.5+) [1] Created commit 5a16ac5 in eds master (3.11.5+) Created commit 285c672 in evo master (3.11.5+) Created commit 18f9966 in eds gnome-3-10 (3.10.4+) Created commit b47a02a in evo gnome-3-10 (3.10.4+) [1] https://git.gnome.org/browse/evolution-data-server/commit/?id=c7ef1c9
(In reply to comment #4) > Seems to be dupe of #710080 Oops, I'm sorry, I just committed a fix for this with a reference to this bug, thus I'm changing the duplicate order ;)
*** Bug 710080 has been marked as a duplicate of this bug. ***
*** Bug 665056 has been marked as a duplicate of this bug. ***
*** Bug 675665 has been marked as a duplicate of this bug. ***
This problem was fixed for me in 3.10.4, but it's present again in Evolution 3.12.1.
I guess this is after changes in bug #721286 and maybe other bug reports. Is this s regression between a switch from 3.12.0 to 3.12.1, or the switch from 3.10.4 to 3.12.1? The difference is that the former means that something broke in the update; the later means that you run evolution 3.12.x for the first time, which makes sure the flags shown in evolution correspond with the server state, thus if the older evolution failed to save anything to the server, but stored locally that the message was read, then the 3.12.x syncs the state with the server and shows those "possibly-read" as "unread". Once the initial desync with the server is cleaned-up, everything will work as expected (or even better than that, because the pretend of the message being read, while the server had stored that it wasn't, was a headache.
Your guess probably explains why some of my very old mails have come back as Unread, but I'm experiencing this issue primarily with brand new messages, so something's definitely wrong in the latest version. I can reproduce this fairly reliably following the procedure in comment #0. I did not try 3.12.0. I can confirm the bug exists in 3.10.3 and 3.12.1, but not 3.10.4.
Aah, I see, I didn't notice the details in comment #0. That's a pretty usual behaviour. The idea is that if you issue a quit request, then evolution tries to quit as quickly as possible, which involves any pending operation cancel. That means, if the upload of changes is in process, then it is cancelled and the changes are not propagate to the server. The next evolution start the folder is updated with server-side flags, thus eventually marked as unread. It might probably broke in combination with commit [1], but I tested to not break the quit. I did it wrong, it seems. [1] https://git.gnome.org/browse/evolution/commit/?id=d569f7d87
Hmm, I cannot reproduce this reliably, somehow. Using 3.12.2 (which might be basically the same as yours 3.12.1), I: a) enter a GMail's Inbox, mark several messages unread; b) immediately quit evolution (by clicking the "x" button in the window's title bar). c) run evolution and enter the same folder, the messages are left unread. d) select them all and mark them read e) close evolution and start it again, the flags are left as they should Despite this, I recall I saw something similar, I just cannot reproduce it on will and see it rather sporadically, than often.
I get the same result as you -- no bug -- when following those steps. I've been trying to recreate this today so that I can get a debug log for you (is running with CAMEL_DEBUG=all sufficient?), but it's working fine today. This is frustrating, since I normally get spurious unread messages normally every time I open my email. (Maybe it works sometimes and not others, and I simply only notice when it's broken....)
(In reply to comment #16) > (is running with CAMEL_DEBUG=all sufficient?) Please use: CAMEL_DEBUG=imapx after all, that is what we want to debug. I'm also unhappy when I cannot reproduce bugs while I know the things are broken there in some way which I try to figure out. :)
The reason I haven't responded with a debug log is that Evolution has been far more reliable this week: I only hit this bug once all week, while previously it would happen almost every time I opened Evolution. So it's effectively fixed for me, even though I'm still using 3.12.1 (as 3.12.2 seems to have missed the Fedora copr). I notice that a separate bug where filters were not properly applied (which I had not yet reported on Bugzilla) also disappeared at the same time as this one.
Created attachment 289815 [details] Output of CAMEL_DEBUG=imapx:io evolution
I'm using Evolution 3.12.7 on Ubuntu 14.04.1 LTS and am having the same problem. I've attached a debug output.
Thanks for the log. Do you recall which folder was affected, please? Reading 240K lines of a log and spotting the issue out of blue would be a nice catch. All the UID STORE requests in the log finished successfully, at least according to the log. It seems to me that all the UID STORE commands were done on the Inbox folder. I believe this is related to bug #738724, whose fix landed after the evolution-data-server 3.12.7.1 release, thus it'll be part of 3.12.8 release the next week. *** This bug has been marked as a duplicate of bug 738724 ***
You're welcome and as far as I can tell it's only the 'Inbox' folder that is affected. Scanning through the output I see from lines 38551 - 38581 (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion 'closure->ref_count > 0' failed The same at 40789, 41264, 152654, 190294, 191747, 191983, 192136 and more following that. Of course I have no idea whether this has anything to do with the issue or not.
(In reply to comment #22) > (evolution:18745): GLib-GObject-CRITICAL **: g_closure_unref: assertion > 'closure->ref_count > 0' failed These use to be shown since certain webkit version, though to be sure a backtrace of the warning would show which part generates it. In any case, the flag save doesn't use GClosure, thus it might not be directly related to the changed flags saving. (I guess a new warning is printed whenever you change selected message in the message list.)