1090481 - [email] Log periodic sync summary to IndexedDB that is easily exportable

Status: RESOLVED WONTFIX

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

Description

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

In order to address the general family of bugs about experiencing problems with periodic sync (ex bug 1018828 and things duped to it) we need logs to capture the result of periodic sync.  Although there are various logging options currently available, they vary between "a hassle" and "impractical", largely owing to the fact that our in-memory circular log buffer inherently gets flushed if the email app closes itself at the end of the cronsync run.

This is the type of thing we could get infinitely fancy on.  Given the inherent hassle of dealing with the necessary IndexedDB upgrade (unless we use ad-hoc DeviceStorage), I think it's worth getting slightly fancy.


I propose we do the following to keep this sanely scoped but have an improvement gameplan that doesn't require us to re-do things when we get fancier:

- This new functionality is opt-in via secret debug menu for production.  For some Moz dogfooding/development builds, it might make sense to turn this on by default (at privacy-preserving levels.)

- Have cronsync.js push a "slog" listener for the duration of the cronsync process and persist the results of that durably before anyone calls window.close().  This would log into a list of strings (immediately snapshotting object state).  MailUniverse might want to be involved in this with the concept of a 'daemon task' and with the front-end telling the back-end when it starts up just for cronsync purposes to make sure we have that buffer going from the word go.

- Create an IndexedDB objectstore "debuglogs" with keys that look like "cronsync:TIMESTAMP" or "errorsnap:TIMESTAMP".  We're only doing cronsync now.  The idea is that we could do some type of reasonably efficient rolling log purging where we only keep the last N days.  Unfortunately, that assumes the system clock is at all reliable.  Which (fortunately means) we only implement a "nuke logs completely" button (with confirm).

- Have a button that gets all the current logs from the database and writes them to DeviceStorage as a big JSON file, like we currently do.  Have this throw up a confirm to let you know that it wrote them to disk and to ask whether you'd like to purge the DB.


Future work would be doing things like having slog maintain a circular buffer that gets snapshotted and written to the DB when a full-blown error is reported.  (With the log then getting cleared to avoid having a huge circular buffer redundantly persisted to disk multiple times.)

Comment 1

[BMO Automation]

Firefox OS is not being worked on