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
- Threads: N1 always asks for the 'expanded' view, so K2 just always returns
the expanded view. N1 no longer needs to specify this.
- Messages: N1 only needed a 'count' view to display the initial sync progress
We've removed this progress bar and the corresponding request.
Summary:
Fixes a test that was broken due to my unfamiliarity with
CoffeeScript :-/
Test Plan: Tests
Reviewers: bengotow
Reviewed By: bengotow
Subscribers: juan
Differential Revision: https://phab.nylas.com/D3302
Summary:
This should help us avoid the thundering herd problem if we have some
kind of API outage affecting a wide number of clients.
Test Plan: Tests
Reviewers: bengotow
Reviewed By: bengotow
Subscribers: juan
Differential Revision: https://phab.nylas.com/D3297
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
When APIRoot is using https, the port will forced to be 443 even when APIRoot
indicates another port. This is because of the line options.port = 443
overwriting the correct options.port extracted by url.parse. This is fixed by
removing the problematic line. The default port is still 443 if you look into
https.js. In case we want a different default port in the future, we can do
options.port = options.port || 443.
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
Summary:
This diff is designed to dramatically speed up new window load time for
all window types and reduce memory consumption of our hot windows.
Before this diff, windows loaded in ~3 seconds. They now boot in a couple
hundred milliseconds without requiring to keep hot windows around for
each and every type of popout window we want to load quickly.
One of the largest bottlenecks was the `require`ing and initializing of
everything in `NylasExports`.
I changed `NylasExports` to be entirely lazily-loaded. Drafts and tasks
now register their constructors with a `StoreRegistry` and the
`TaskRegistry`. This lets us explicitly choose a time to activate these
stores in the window initalization instead of whenever nylas-exports
happens to be required first.
Before, NylasExports was required first when components were first
rendering. This made initial render extremely slow and made the proposed
time picker popout slow.
By moving require into the very initial window boot, we can create a new
scheme of hot windows that are "half loaded". All of the expensive
require-ing and store initialization is done. All we need to do is
activate the packages for just the one window.
This means that the hot window scheme needs to fundamentally change from
have fully pre-loaded windows, to having half-loaded empty hot windows
that can get their window props overridden again.
This led to a major refactor of the WindowManager to support this new
window scheme.
Along the way the API of WindowManager was significantly simplifed.
Instead of a bunch of special-cased windows, there are now consistent
interfaces to get and `ensure` windows are created and displayed. This
DRYed up a lot of repeated logic around showing or creating core windows.
This also allowed the consolidation of the core window configurations into
one place for much easier reasoning about what's getting booted up.
When a hot window goes "live" and gets populated, we simply change the
`windowType`. This now re-triggers the loading of all of the packages for
the window. All of the loading time is now just for the packages that
window requires since core Nylas is there thanks to the hot window
mechanism.
Unfortunately loading all of the packages for the composer was still
unnaceptably slow. The major issue was that all of the composer plugins
were taking a long time to process and initialize. The solution was to
have the main composer load first, then trigger another window load
settings change to change the `windowType` that loads in all of the
plugins.
Another major bottleneck was the `RetinaImg` name lookup on disk. This
requires traversing the entire static folder synchronously on boot. This
is now done once when the main window loads and saved in a cache in the
browser process. Any secondary windows simply ask the backend for this
cache and save the filesystem access time.
The Paper Doc below is the current set of manual tests I'm doing to make
sure no window interactions (there are a lot of them!) regressed.
Test Plan: https://paper.dropbox.com/doc/Window-Refactor-UYsgvjgdXgVlTw8nXTr9h
Reviewers: juan, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2916
- Make the retry interval go 2 sec, 3.4s, 6 sec...
- Only show the connection status bar if the interval is > 5 seconds, in case the error was temporary.
- Do not show sync errors in the sidebar. The only available action is "Try Again", and we try again on our own. The error is frustrating and the user can't do anything about it anyway.
Summary:
This diff includes several updates:
- Update sqlite version to use FTS5
- Adds new methods to DatabaseStore to create and update Search Indexes
- Currently indexing subject, participants, and thread message bodies or snippets if the body is not available
- Update initial sync to fetch 5000 message bodies per account
- Adds a new SearchMatcher
- Add new thread-search-index package to run in the worker window to
init and keep thread search index up to date
- Converts Thread to ES6
TODO:
- Remove/Update suggestions dropdown
- Add tests
Test Plan: - TODO
Reviewers: evan, bengotow
Reviewed By: evan, bengotow
Differential Revision: https://phab.nylas.com/D2826
Summary:
The TaskQueue does it's own throttling and has it's own processQueue retry timeout, no need for longPollConnected
Remove dead code (OfflineError)
Rename long connection state to status so we don't ask for `state.state`
Remove long poll actions related to online/offline in favor of exposing connection state through NylasSyncStatusStore
Consoliate notifications and account-error-heaer into a single package and organize files into sidebar vs. header.
Update the DeveloperBarStore to query the sync status store for long poll statuses
Test Plan: All existing tests pass
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D2835
Summary:
- Was not properly updating the references to snoozed categories when
accounts were added or removed
- Update whenCategoriesReady to make sure we listen until category syncing has concluded (Move inside CategoryStore)
- #1676, #1658
Test Plan: - TODO
Reviewers: evan, drew, bengotow
Reviewed By: bengotow
Differential Revision: https://phab.nylas.com/D2723
