837279 - When going online/offline, syncing can toss out all messages and then create lots of network activity with no UI changes

Status: RESOLVED WORKSFORME

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This happened very late at night/early in the morning, so I don't have a log, but I think the STR were something like
 (1) Go online
 (2) Sync account, sync completes
 (3) Start another sync
 (4) Drop network connection

Email got into a state where
 A. Didn't display any previously-synced messages.  (I know they were still there because they came back after restarting Email.)
 B. Forever showed "Loading messages ..." spinner
 C. Caused continuous network activity (as indicated by network spinner)

For v1 target markets, I think continuous network use without and UI response or indicator where it's going is a possible blocker.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I emailed myself STR that I think were for this before passing out

- offline, luanch email, see cached
- go online
- refresh, nothing happens
- go to other folder.. Load spinner, never gets anywhere
- go back to furst folder.  Ssme but had cached messages

Comment 2

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

There's a bug in IMAP synchronization that I have a fix for in my pending fix for bug 822882 where synchronizations can enter a "voracious zombie" state where they don't realize they are dead and never have their fill of messages/brains, so the folder synchronizes until one of the other constraints (ex: the folder got entirely synchronized) becomes satisfied.  In your STR, this would have happened when you returned from the other folder to the first folder; the refresh itself was not capable of causing that to happen.  This should cover the v1.0.0 issue.

I am assuming network spinner is the thing in the system status bar at the top of the screen.


There is potential other interesting stuff in here too, though.  Do you know what you meant by "go online"?  For IMAP, if navigator.onLine tells us we are online, we will enter a finite back-off sequence, at the end of which we will tell you we couldn't talk to the server and let you trigger a retry.

Comment 3

[Alex Keybl [:akeybl]]

Adding qawanted. Before blocking on what appears to be an edge case, we need to know what the user would need to do to get out of this situation. Just reconnect to the network?

Comment 4

[Mila Davydova]

I was able to reproduce this issue on Unagi device build ID 20130208070201 with Dec 5th Kernel
Load spinner continues to spin and never gets anywhere when switching to another folder (as it specifies in comment 1).
 I was able to get out of this situation by reconnecting to the network, closing the email app through the cards view and re-launching the email app again.

Comment 5

[Alex Keybl [:akeybl]]

(In reply to Mila Davydova from comment #4)
>  I was able to get out of this situation by reconnecting to the network,
> closing the email app through the cards view and re-launching the email app
> again.

The user can work around this likely uncommon issue - we didn't hear about this as a regular part of the dogfooding program. Tracking instead.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This was with IMAP, so I hope it goes away with bug 822882.

Comment 7

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

I believe this was likely resolved a long time ago; if not by when the fix landed for bug 822882 (should have marked a dep; whoops!), then by improvements to handling closed connections (with unit tests) and our failsafe logic to kill idle IMAP connections.  In truth, the TCP stack's retry knobs might not be aggressive enough at giving up and the RIL might not be good enough at tearing down existing connections, but that now only impacts SMTP.