865786 - [email/IMAP] timezone probing code can break during account creation, causing account creation to fail

Status: RESOLVED WONTFIX

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

Description

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

Attachment: bad timezone log from bug 863807

In the provided log, the timezone probing code appears to be stepping backwards repeatedly in an attempt to find a range that matches its search.  The base case backstop does not appear to be working correctly, so we generate an illegal search pattern and then die.  (Presumably there are simply no messages in the folder and we could fast-path an EXISTS 0 check on out.)

Of course when the base case hits the bottom and we fail to find a timezone, we are then in pathological INTERNALDATE failure mode because we will guess and guess wrong.  So a fix for this case would really want us to include an INTERNALDATE slop-compensating fix.

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

What's the user impact here?

Comment 2

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

(In reply to [e-mail] from comment #1)
> What's the user impact here?

We will be unable to create IMAP e-mail accounts where there are no messages still in the inbox belonging to the UID range containing the 50 most recent messages.  This would be most likely to occur to the accounts of those using a large number of mail filters to move messages out of the inbox, or who otherwise keep their inbox clean by promptly deleting new messages.  The problem will go away when a new message is received.  Test accounts which don't receive a stream of new messages and are periodically cleaned out for testing reasons are more likely to get bit by this (although only ever few months).

I believe I've identified the bug (need to write a proper unit test of course); our deepening routine is missing a 'return' and fall through into a case which causes us to make an illegal fetch which synchronously generates an exception which propagates back out to imap.js and breaks its state machine, so then when our properly issued, legal search result comes back, we fail to process the data, resulting in a failure that does not time-out properly.

Comment 3

[Alex Keybl [:akeybl]]

Is this a regression from v1.1? If not, this is pretty corner case (which is why we wouldn't block v1.0.1 either).

Comment 4

[Mike Lee [:mlee]]

Adding c= whiteboard to get this into the scrumbugs backlog.

Comment 5

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

(In reply to Alex Keybl [:akeybl] from comment #3)
> Is this a regression from v1.1? If not, this is pretty corner case (which is
> why we wouldn't block v1.0.1 either).

There is no recent regression; this problem has existed since the code landed a long time ago.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Not blocking since this looks like a significant technical overhaul and would be better off going into the scrum backlog for prioritization and investigation of best solution.  It can be nominated for uplift when ready and if risk to taking is deemed low.

Comment 8

[BMO Automation]

Firefox OS is not being worked on