[email] queued header operation on a message no longer in the database breaks sync

RESOLVED FIXED in B2G C3 (12dec-1jan)

Status

P1
normal
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: dietrich, Assigned: asuth)

Tracking

unspecified
B2G C3 (12dec-1jan)
ARM
Gonk (Firefox OS)
Bug Flags:
in-moztrap -

Firefox Tracking Flags

(blocking-basecamp:+)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
logcat: http://pastebin.mozilla.org/2002174

I can choose other folders, and they load. But Inbox never does.
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
(Assignee)

Comment 1

6 years ago
This should most definitely be blocking.

From the log (thank you!), the problem is that we have a queued operation on a header ('modtags') that is no longer known to the database.  The _partitionAndAccessFoldersSequentially helper effectively asserts and dies, taking the mutex with it so nothing can ever happen in the inbox again.

The actual 'modtags' operation expects and handles this situation, so it's mainly a question of exposing a null serverId in the case we're asserting on for modtags rather than dereferencing a null object and dying.  I will also want to audit the other IMAP 'do' operations and add test cases that trigger this code path in both server-initiated and local move/delete operation varieties.
Status: NEW → ASSIGNED
QA Contact: nhirata.bugzilla → bugmail

Comment 2

6 years ago
Just a comment:  I've had the same problem running Thunderbird 17.0 on both Windows 7 and Windows XP.

When I reinstalled Thunderbird 16.02, everything worked fine.
blocking-basecamp: ? → +
Priority: -- → P2
Target Milestone: --- → B2G C3 (12dec-1jan)
Assignee: nobody → bugmail

Updated

6 years ago
Priority: P2 → P1
(Assignee)

Comment 3

6 years ago
Created attachment 693799 [details] [review]
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/102

Here's the fix and the unit tests previously described.

I audited/filled out the IMAP usages.  I implemented early bail logic if we end up with nothing to ask the IMAP server because it's not legal for us to ask to manipulate 0 messages.

I also audited the ActiveSync usages.  They are fine, although we may issue requests with 0 messages.  I think this might be okay for ActiveSync?  I am not sure, but it's not as major an issue as what I fixed in this bug because...

We already have logic in place that eventually gives up on local operations after they experience multiple failures trying to run.  The trick there is that we can only do that if the job completes with a failure status, and in this bug we were throwing an exception at a time/place where it would not be caught and converted into a job failure.

If it turns out ActiveSync gets angry if we try and post a request to it with no actions taken, we should change this in a follow-up.  The unit test work for these edge cases is more significant, especially for ActiveSync where the fake server would need to be enhanced I suspect.
Attachment #693799 - Flags: review?(squibblyflabbetydoo)

Updated

6 years ago
Attachment #693799 - Flags: review?(squibblyflabbetydoo) → review+
(Assignee)

Comment 4

6 years ago
landed on gaia-email-libs-and-more/master:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/102

landed on gaia/master:
https://github.com/mozilla-b2g/gaia/pull/7122
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 5

6 years ago
This issue does not reproduce with unagi, build ID 20121231070201
Status: RESOLVED → VERIFIED

Comment 6

6 years ago
(In reply to Mila Davydova from comment #5)
> This issue does not reproduce with unagi, build ID 20121231070201

I just downloaded and installed Thunderbird 17.0.2 on a Windows 7 Starter OS.  Same problem occurred; IMAP download on GMAIL inbox just spins and spins and spins -- never downloads.

I uninstalled 17.02, reinstalled 16.02 -- still works fine.

Comment 7

6 years ago
This bug doesn't have anything to do with Thunderbird. You should file a separate bug.
This still occurs on nightly pvt.  You would have to be on a build that has the master branch of gaia in order to verify that this is fixed.

STR:
1. launch email 
2. set up gmail account
3. open an email and mark it then move the file to starred
4. go to the starred directory
5. go back to inbox

Expected: loading messages will finish
Actual: stuck at the loading messages
Status: VERIFIED → RESOLVED
Last Resolved: 6 years ago6 years ago
Oh wait... this was fixed over 2 months ago?  I guess I'm running into a regression then?
(Assignee)

Comment 10

6 years ago
All kinds of stuff could break sync; it's almost entirely unlikely that it was this bug.  I'm retitling the subject to help clarify what the actual problem was.
Summary: Email app stuck loading Gmail inbox, never gets past "loading messages" → [email] queued header operation on a message no longer in the database breaks sync

Comment 11

6 years ago
I have had the same problem -- gmail accounts inboxes never load -- for all versions of Thunderbird 17.0 - 17.02.  I'm currently running 16.02, which works fine.  This bug -- whatever it is -- is not fixed.
(Assignee)

Comment 12

6 years ago
(In reply to clanier00 from comment #11)
> I have had the same problem -- gmail accounts inboxes never load -- for all
> versions of Thunderbird 17.0 - 17.02.  I'm currently running 16.02, which
> works fine.  This bug -- whatever it is -- is not fixed.

This bug still has nothing to do with Thunderbird; bugs for Thunderbird live under the Products "Thunderbird" or "MailNews Core".  I'm removing you from the cc to help avoid further confusion.

Please check out https://support.mozillamessaging.com/en-US/home for Thunderbird support; there is probably something wrong with your profile/account setup, and you will want to either re-create the account or the profile.

Updated

6 years ago
Flags: in-moztrap-
Attachment mime type: text/plain → text/x-github-pull-request
(Assignee)

Updated

3 years ago
QA Contact: bugmail
You need to log in before you can comment on or make changes to this bug.