Mailspring/internal_packages/notifications
Ben Gotow 215fa0e4cb fix(initial-sync): When an error is encountered, do not start fetching from zero again
Summary:
Previously, when an error was encountered during initial mailbox sync we just started it
over after a retry delay. Recent API uptime issues mean that this was happening often and lots of
people were seeing sync retry many times. This is bad because the app is less performant while
it's syncing mail, and also generates unnecessary load as the app re-fetches threads it already has.

In this diff, there are new specs and functionality in nylas-sync-worker to start fetching
where we left off. This is typically going to be OK because the default sort ordering of the
threads endpoint is newest->oldest, so if new items have arrived since we started fetching
and page boundaries have changed, we'll get duplicate data rather than missing data. Connceting
to the streaming API as soon as we start the sync also ensures that we roll up any changes to
data we've already paginated over.

Test Plan: Run tests

Reviewers: drew, evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D2132
2015-10-08 19:02:54 -07:00
..
lib fix(initial-sync): When an error is encountered, do not start fetching from zero again 2015-10-08 19:02:54 -07:00
spec fix(notifications): Give notifications tag like HTML5 Notifications so you can de-dupe 2015-05-25 10:27:36 -07:00
stylesheets fix(notifications): Add a purple tint color for developer notification 2015-10-04 00:22:59 -07:00
package.json fix(speed): Mark packages as engine:atom, don't include coffee,cjsx in compiled app 2015-03-20 17:53:11 -07:00