Since message IDs are now static but there's no good way to generate
static thread IDs while syncing an account from newest message first,
we give threads the ID of any message on that thread and, when setting
metadata, look up the local thread ID by first going through the
message table.
Also changed the DeltaProcessor so it doesn’t query for models before sending out `Actions.didPassivelyReceiveCreateDeltas`, and renames it to be more clear it’s about deltas.
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:
This is an initial attempt to fix an issue we’ve had with long-running queries interrupting the N1 user experience. Node-sqlite3 used an async approach that ran sqlite’s synchronous query methods on a worker thread, but doing that involves copying memory more and node-sqlite3 was just generally slow.
However, moving to better-sqlite3 made /everything/ synchronous. Even with the right indexes some of our queries just suck.
This diff adds `DatabaseStore.findAll(…).background().then()` which allows you to mark a query as “unimportant”. These queries are run in a separate process which is forked from the window and can take an extra 10-50ms to complete. That said, they’re totally async and don’t jam up the app.
I’m personally a fan of the flag and less a fan of the implementation. The “agent” process can handle many queries in it’s lifetime if they keep coming and quits after 10 seconds of inactivity. (Both to save memory and to avoid scenarios where it might end up oprhaned and running forever). While running it uses about 40MB of RAM, which is a bit on the crazy side.
Test Plan: No new tests yet
Reviewers: evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D3420
