933079 - [e-mail] gmail connections not noticing new messages properly, suspect gmail IMAP caching behaviour

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

In the logs for bug 932566 on notifications, it appears that gmail is receiving new messages but our synchronization is not seeing them.  For example, in the log at https://bugzilla.mozilla.org/attachment.cgi?id=824983 as noted in my analysis on https://bugzilla.mozilla.org/show_bug.cgi?id=932566#c9, the folder clearly knows about a new message, but our SEARCH is not finding the message.  The preceding log at https://bug932566.bugzilla.mozilla.org/attachment.cgi?id=824697 is showing similar data.

The key things are:
- we are reusing the same connection
- the folder message count goes up.  (This goes up as a result of an EXISTS notification, which can either be unsolicited or something that's the result of SELECT/EXAMINE.)
- in the case where we did see the new message in the log (attachment 824697 [details]):
-- in the first SEARCH NOT DELETED SINCE 29-Oct-2013 we hear about the message thanks to an increase in the folder message count, but we don't see the message
-- in the second SEARCH NOT DELETED SINCE 29-Oct-2013, we see the message and report INTERNALDATE:  30-Oct-2013 15:54:04 +0000.  This timestamp very safely satisfies our search criteria no matter what timezone you attribute the message to.


There are a few possible explanations.

A) Google, having an unusual and custom IMAP implementation does some caching.  Our connection is not seeing the new data (in its entirety) because we are not doing something to force the connection to refresh its data.  In bug 883464 we stopped invoking IDLE because we were not making use of it.  It's possible that we need to issue an IDLE or do a more blatant folder SELECT/EXAMINE in order to get our view of the world updated.

B) Google is buggy or overloaded sometimes / during those tests and there's not much we can do about it.

C) Some other bug.


If this is a caching, the user work-arounds are to do one of the following:
- Wait for the connection to update its cache on its own.  It seems like this happen given those logs.
- Have the user explicitly kill the app, thereby killing any lingering TCP connections.  This will also cause the app to close whenever itself if it wakes up because of a mozAlarm, so every time it wakes up it will establish a new connection.  (If the e-mail app was ever open when it wakes up from a mozAlarm, it will not close itself when the cronsync process completes.)


I'm marking this as a blocker of bug 932566 now, although it's possible that bug should maybe just get duped to this one or something like that.

Comment 1

[Jason Smith [:jsmith]]

See the discussion on bug 932566 for reasoning for the blocking nomination. Specifically:

- gmail issues: this seems like bug 933079 may be causing us to not find anything until the second poll interval.  I definitely think this is a serious bug, and I definitely think we want to address this one before we ship.

In https://bugzilla.mozilla.org/show_bug.cgi?id=932566#c15.

Comment 2

[Preeti Raghunath(:Preeti)]

Broken new feature hence koi+

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Marking NO_UPLIFT to forbid automated uplift so we can manually prepare/verify the v1.2 uplift once this gets fixed.

Comment 4

[bhavana bajaj [:bajaj]]

:asuth is there an eta when this will be resolved ? Will help QA align/allocate testing resources.

Comment 5

[Marcus Cavanaugh [:mcav]]

I'm going to take a look at this on Monday/Tuesday and will post an update as soon as I have an ETA. Likely be resolved late next week.

Comment 6

[Marcus Cavanaugh [:mcav]]

Attachment: GELAM Pull Request

Comment 7

[Marcus Cavanaugh [:mcav]]

Gmail IMAP servers cache SEARCH results. When Gmail notifies the connection (via unsolicited responses) that new messages have arrived, it updates the SEARCH results to include the latest messages. Sending a command like NOOP/CHECK triggers the necessary cache invalidation, allowing SEARCH to return all new messages as expected.

This patch sends a NOOP before syncing-SEARCH requests for Gmail IMAP servers. Testing using a Gmail account, I was able to reproduce the bug without the patch, and see it corrected with the patch. Fortunately it's a very simple fix, so we should be able to land this quickly.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8333962 [details]
GELAM Pull Request

Awesome!  Great targeted fix, love the comment.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Note: I had marked this NO_UPLIFT just for safety in case our hunk ended up being bigger than desired for Gaia.  I think it's easy enough for you to just cherry-pick, sanity check the hunk, then land, but this is an extremely straightforward patch and the hunk will be minimal too, so, whatever you want.

Comment 10

[Marcus Cavanaugh [:mcav]]

Landed in Gaia master: https://github.com/mozilla-b2g/gaia/commit/0b4d248a03a9f819a400ee9039d0594b2d7bd9c6

Uplifted to v1.2: https://github.com/mozilla-b2g/gaia/commit/9439907a255e04de4c33493fe03d6670c8256e2f