1015543 - message that was trying to send when E-mail app is killed is no longer saved to "Local Drafts"

Status: RESOLVED WONTFIX

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

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I *think* this is a regression, though I'm not 100% sure.

I think it used to be that if I composed and hit the send button on an email, and the sending process hung (see also bug 865270), and I then closed the email app while it was trying to send, the message would be in Local Drafts.  That seems no longer to be the case.

Steps to reproduce:
 1. connect to wireless
 2. open the email app and compose an email
 3. walk away from the wireless signal, and just before getting out of range, hit send
 4. walk further out of range, as the sending hangs
 5. hold down the home button until the app switcher appears
 6. click the (X) to close the email app
 7. restart the email app
 8. go to the local drafts folder

Expected results:
  The message that was trying to send should be there.

Actual results:
  Empty.

(I'm testing against a master user build from sometime Wednesday, gaia revision 9b2b0b918fc91f834b3539e1fa77663b8b30b0c6.)

Comment 1

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

The highest probability on this is that IndexedDB failed to persist our transactions to disk for a while and we didn't notice.  In a decision I've come to regret for multiple reasons, database writes are issued blindly in a write-through fashion.  We do not wait for them to return.  Other than logging an error to console.error, we do nothing if a write fails.

This was done for latency reasons; why wait for I/O if you don't need to wait for I/O?  Related to this, we perform sufficient caching so that we can effectively operate despite the complete failure of the storage subsystem in this case.

Are you using a device like a ZTE Open or Alcatel One Touch that has super-tiny system storage (where we keep our IndexedDB)?  They have ~100MBish of storage, which is not a lot.  SD cards don't help.  And we store all encoded attachments for drafts in IndexedDB.  (The good news is they are stored as blobs outside of the SQLite database which doesn't actually shrink.)

Comment 2

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

Er, but, so anywho, what we would ideally want is a logcat a la https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo from when things went bad.  However, for my theory, just doing "adb shell df" is sufficient.

Comment 3

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

Additional thought: the reason your send could have hung is that we do need to issue a read against IndexedDB when attaching attachments because we want IndexedDB disk-backed Blobs/Files rather than whatever the web activity gave us (which could be a memory-leaky memory-backed Blob).  If you attached an attachment, the send process will absolutely hang since our operation queue would likely fatally die.  All messages without attachments have a good chance of sending and you not being the wiser.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I'm using a hamachi.

I've never seen sending not hang when I was just about out-of-range of the wifi; it's pretty common for me to think of things to email myself while I'm in the elevator on the way out of the office, so it's one of the more frequent times for me to use the email app.

$ adb shell df
Filesystem             Size   Used   Free   Blksize
/dev                    90M    48K    90M   4096
/mnt/asec               90M     0K    90M   4096
/mnt/obb                90M     0K    90M   4096
/system                200M   169M    30M   4096
/data                  161M    91M    69M   4096
/persist                 4M   780K     3M   4096
/cache                  40M     4M    35M   4096
/mnt/sdcard              1G    78M     1G   4096
/mnt/secure/asec         1G    78M     1G   4096

Comment 5

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

My theory is sadly not supported by the facts (thank you for those!).  /data has more than sufficient space.  And secret debug mode is of no use in a situation where you can't escape from the send UI to get to the secret debug mode to save the logs.  (https://wiki.mozilla.org/Gaia/Email/SecretDebugMode)

The code straightforwardly saves the draft before sending and only deletes it when sending has completed with a non-error.  The hang (regrettably not super surprising in general, but we'll pretend it's because of you hanging out in faraday cages) should mean that we do not explicitly delete the draft.

Which then implies this is still a cascading failure from something else breaking the job/operation queue.  I trust your analytical skills, so one possibility is that this is an elevator-correlated failure intersecting with sending and periodic sync.  Specifically, as long as the screen is on, wi-fi is on.  Wi-fi turns off when the screen turns off, except if we are holding a wake-lock because sending in process.  Periodic sync is not network aware and runs regardless of network status.  If sync fails on bad wi-fi, sync (which holds our regrettable mutex) could break things in a way that hangs sending.

This may or may not also be fanciful, the key questions to you is whether you have periodic sync enabled for email or not.

But in general most useful is the logcat (https://wiki.mozilla.org/Gaia/Email/RequiredBugInfo).  Assuming you carry around a laptop, the ideal situation would be you see the hang occur in the elevator and then pull out your laptop and grab a logcat before the circular buffer overflows.

If you can't furnish a logcat, I'll try and do a static investigation during the feedback/review process for background sending.  :mcav may also have already found such a risk too, cc'ing explicitly.

Comment 6

[BMO Automation]

Firefox OS is not being worked on