Summary:
This diff is a rename. No logical changes.
We used to have a set of files called `nylas-sync-worker`. In Old N1 these
used to have a lot of logic to slowly sync mail from our API. Since we
exclusively use local-sync via a soon-to-be-obsolesced delta stream, these
files really just manage the delta streaming connection.
It's incredibly confusing to have a set of files called worker-sync when
there's a sync-worker already in the codebase. This renames everything to
refer to them as account sync workers.
The reason I wanted this rename is because the IdentityStore on initial
launch triggers and fires a fairly scary-sounding
`Actions.refreshAllSyncWorkers()`. In reality all it does is
`Actions.refreshAllDeltaConnections()`. I'm also tired of staring at files
for a full minute before realizing that this is not the sync worker I was
looking for.
Test Plan:
After rename, booted the app and ensured that deltas were coming through
for new mail and no errors were being thrown
Reviewers: halla, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3767
This reverts commit ee5609bdb0.
Updates to nylas sync worker to support multiple cursors
Convert NylasSyncWorker to es6
Convert NylasSyncWorkerPool to es6
Extract into deltaProcessor
Update names to NylasSyncWorker state
Working on spec fixes
More spec fixes
Delta stream refactor fixes
NylasLongConnection ends the connection when the 'end' event is emitted
by the `request` object. When this happens, the global connection buffer is cleared.
Also, the global buffer holds the data we've received from the connection, and
whenever we receive new data, we accumulate it in the buffer and call a processBuffer function
which is throttled to 400ms.
Given that the buffer is global state, and processing occurs
asynchronously with a delay of up to 400ms, if the 'end' event on the connection is
fired before we actually get to process the buffer, we would clear it and show no results.
This scenario currently only affected search because if we accidentally
threw away some data when streaming deltas, we will get that data again
when we reopen the delta streaming connection.
- Completely remove nylas-long-connection.coffee file and consolidate all logic into
nylas-long-connection.es6 and worker-sync/delta-streaming-connection.es6:
- Separate it into DeltaStreamingConnection which is specific to the worker-sync
package for handling deltas
- NylasLongConnection is a "reusable" persistent connection to our API
which is also used by the search package
- This is a basically a fixed revision of https://phab.nylas.com/D2875,
see difff for more info
- Makes it so delta streaming does not retry so aggressively on 403s, which
happens whenever a user’s trial has expired
Summary:
- Remove nylas-long-connection.coffee duplicate code from sync worker package
and replace with delta-streaming-connection which uses NylasAPI.longConnection
- Replacement for XHR will come in another diff -- still need to clean up and
fix some edge cases
Test Plan:
- TODO! Will add test coverage for NylasLongConnection and
DeltaStreamingConnection
Reviewers: evan, bengotow
Reviewed By: evan, bengotow
Differential Revision: https://phab.nylas.com/D2875
