GNOME Bugzilla – Bug 714865
Use status command to get accurate unread count
Last modified: 2014-03-03 23:08:36 UTC
---- Reported by eric@yorba.org 2013-06-28 17:25:00 -0700 ---- Original Redmine bug id: 7180 Original URL: http://redmine.yorba.org/issues/7180 Searchable id: yorba-bug-7180 Original author: Eric Gregory Original description: Geary's unread count can become inaccurate when the status command hasn't been run recently. We've decided the best way to handle this is to fire the status command a few seconds after something changes the unread count (i.e. new messages, user reading a message, etc.) This way if the unread count gets out of sync, it will quickly be corrected. Related issues: related to geary - 7244: Unread count increased/decreased when marking out-of-fold... (Fixed) related to geary - 7145: Unread message counts don't appear until connected (Fixed) related to geary - 7490: unread message count is wrong after sending to self (Fixed) related to geary - 7579: reading a message soon after Geary first sees it leaves a... (Open) ---- Additional Comments From geary-maint@gnome.bugs 2013-10-03 17:53:00 -0700 ---- ### History #### #1 Updated by Jim Nelson 5 months ago Additionally we should increase the background polling interval from 10m to 3m. #### #2 Updated by Adam Dingle 4 months ago I've noticed that Geary's unread message count is often inaccurate. For example, at the moment Geary is displaying All Mail (2) for me, even though when I log into Gmail I see no unread messages in All Mail and a search for label:unread also returns nothing. It's displayed "All Mail (2)" for several minutes now (I'm not sure whether as many as 10 minutes have elapsed). Should this mismatch be considered a symptom of this bug? Or is what I'm seeing a different problem? #### #3 Updated by Jim Nelson 4 months ago This ticket will help correct the mismatch, but there are other problems with unread counts as well. See #7244 and #7145. #### #4 Updated by Jim Nelson 3 months ago * **Priority** changed from _High_ to _Normal_ #### #5 Updated by Adam Dingle 3 months ago The unread count I see in Geary is often accurate and this is one of the bugs I'd most like to see fixed, so it's a little disappointing to see this bug's priority drop to Normal - is this still on the table for 0.4? Just now I started Geary and it's displaying an unread count of 12 for my Inbox. This is odd, since there are only 3 unread messages. When I log into Gmail in a browser, I see an unread count of 3. Aha, wait - after several minutes the unread count did return to 3. I think it's confusing when the count displayed differs from the number of unread messages I actually see for more than a second or two. If we can't hope to keep those in sync that tightly, I'd prefer that Geary simply display a client-side unread count, i.e. the number of unread messages which are available in Geary now. I personally think that would be fine. It seems that the reason we're not displaying that number today is that there might be more unread messages on the server which have not been loaded into Geary, and we want to make the user aware of that fact. The problem is that (for me at least) that's a situation that virtually never happens, whereas an inaccurate Inbox unread count is something I currently see many times every day. #### #6 Updated by Jim Nelson 3 months ago As the Target version indicates, this is still on the table for 0.4. The reason it dropped to Normal is that while unread count isn't perfect, we have issues like crashers and server support issues that won't fly if we had to ship today, whereas this problem is simply narrowing a synchronization window that every IMAP client faces. I can't tell from exactly how you wrote it, but what you're describing may not be solved by this ticket anyway. When Geary first starts it pulls the unread count for all folders on the server -- it's the first thing to happen once the connection is established. It should then update the unread count in the folder list. If it displayed 12 at startup and there was only 3 on the server, it shouldn't take minutes to update unless you have really bad connectivity. Or were you describing a different scenario? In any case, the 1 - 2 second maximum delay you're advocating isn't present in Thunderbird or even Gmail's web interface, which often lags a minute or two (or more). We're currently playing with the polling interval that is used to update this value and can tweak it to whatever value we like. I recently turned it down because too high a value means a lot of extra network traffic. I can move it up, but it comes at a cost. This ticket could help, but it wouldn't be pulling this data down < 1s after the user reads every message. Also note that I suspect we're going to find a basic issue with unread accounting in #7244 that's causing our value to diverge from the server's as the user reads messages; that one's marked High. However, that only corrects updating the value as the user reads messages inside of Geary. I don't see the value in only displaying the number of unread messages in Geary's database; I suspect that would only drive more users to confusion, who would see one number in Geary and another number in Gmail, Thunderbird, and Evolution and conclude Geary was broken. This point of this ticket is to be more selective about pulling this information from the server to avoid excessive blanket polling. We want to get this in to 0.4, but after examining the corpus of issues we're facing for this deadline, I decided that the more invasive tickets had to come first. #### #7 Updated by Adam Dingle 3 months ago OK - thanks for the detailed explanation. I understand that there are tradeoffs here, and yes, we definitely don't want to poll too often. I also certainly agree that crashers and server support should have priority as we move toward 0.4. You asked: > If it displayed 12 at startup and there was only 3 on the server, it shouldn't take minutes to update unless you have really bad connectivity. It did take minutes to update, and I think my connectivity was fine, which was puzzling. I'll let you know if I see this kind of delay again. #### #8 Updated by Charles Lindsay about 1 month ago * **Target version** changed from _0.4.0_ to _0.5.0_ --- Bug imported by chaz@yorba.org 2013-11-21 23:12 UTC --- This bug was previously known as _bug_ 7180 at http://redmine.yorba.org/show_bug.cgi?id=7180 Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
I've got a branch with some ideas for this up at wip/unread-status-714865. I'll run it for a few days and see if it seems to fix the problems for me. Anyone else is welcome to do the same and let us know.
This is what I was thinking of when we discussed the design. So far it seems to be working exactly as hoped. I don't see any code problems. Investigating your patch I found another bug (bug #724910), but I have a patch for that in hand (it's different than what this ticket is solving, it's an order-of-operation problem).
I've been looking at this more, and I've noticed that the unread count for labels sometimes (but rarely) gets exactly doubled when you switch to it. I think what's going on here is that the unread count gets read from the server for all folders, then if you switch to the label before Geary has discovered the new mail there, it adds them again to the unread count as the messages are added to the folder. With this patch, the count is only inaccurate for a second or so, so it's actually much better than it used to be. The only other quick fix I can think of is to do kind of the inverse of this branch: whenever the unread count changes on the server, kick off a folder re-synchronize to immediately download all that mail. Then we could omit unread count manipulation from the email added/removed case, since presumably that email would already be reflected in the unread count. We should talk about this, as I could be missing something. Otherwise, I think doing a more thorough job of record keeping is the only sure way to fix this problem, and that's too much work this late in the milestone. As I said, this is much less noticeable now -- I've triggered this inaccuracy once in the past few days, and if you blink you'll miss it.
Fixed in commit c402001. As we discussed, what we really need is a more thorough accounting method, but that's going to be a much bigger project. This helps a lot in the meantime.