Summary:
fixes T3725
changes:
- show the sync mail activity only if number of deltas received is greater than 10
- make the sync mail activity notification persist for longer, since large deltas (>1k) come in intervals of about 25 seconds, which was greater than our previous timeout interval of 15 seconds
- change to clearer copy
- minor style changes to match new copy
Test Plan: tested manually
Reviewers: bengotow
Maniphest Tasks: T3725
Differential Revision: https://phab.nylas.com/D2051
Summary:
fixes T3563
todo
[x] check with @bengotow and @evan -- does this solution make sense to you?
[x] decide on the actual visual cue to the user -- @bengotow you suggested a loader or spinner, but i was thinking that actual copy should be used so it doesn't look like an unhelpful spinner which goes indefinitely. what do you think of the copy here?
[ ] implement spinner similar to sending a draft
[ ] write tests
[ ] verify that we're showing progress in a helpful way
problem
- new users would see nothing in edgehill after they log in, with no indication on why they can't see any of their mail
- in actuality, our backend is actively pulling all their mail to serve it to edgehill
- new users think edgehill is broken because they're unaware of the work that our backend was doing
solution
- when the backend sends deltas to edgehill, we show a message in the activity bar saying that we're trying to get their mail
- we'll show the sync progress
Test Plan: still need to add tests. all previous tests still green.
Reviewers: bengotow, evan
Subscribers: sdw, bengotow, evan
Maniphest Tasks: T3563
Differential Revision: https://phab.nylas.com/D2032
Summary:
This started when I noticed that drafts weren't dissapearing from the
draft list after send. This was a pretty big bug because if you ever
clicked on one again and tried to re-send it would throw a 400 error
saying the draft id doesn't exist.
This uncovered a few fundamental issues with the DB.
First of all, the reason the draft list wasn't updating was because the DB
trigger that happened when we got in a new message, was being ignored
since the diff contained no drafts (it's now a message).
The bigger issue was that if you had a draft with only a clientId, gave it
a serverId, and tried to call "save", the REPLACE INTO method would not
update the old object, but rather create a second duplicate. This is
because the `id` field was being used as the PRIMARY KEY, and in this
case, that `id` field changed! The fix was to change the PRIMARY KEY to be
the `cilent_id` instead of the `id` and use that as the REPLACE INTO
index.
We still need the `id` field; however, because all of our reads depend on
that field usually being the serverId
Fixes T3507
Test Plan: See new and updated tests
Reviewers: dillon, bengotow
Reviewed By: bengotow
Maniphest Tasks: T3507
Differential Revision: https://phab.nylas.com/D1992
Summary:
Move sync workers and Edgehill token checks to work window
Move the task queue and database setup to the work window
Move ContactStore background refresh to work window
Store the task queue in the database
WIP
The TaskQueue now puts tasks in the database instead of in a file, which also means it can be observed
Move all delta sync and initial sync to a package, make NylasSyncStore which exposes read-only sync state
DraftStore no longer reads task status. Once you set the "sending" bit on a draft, it never gets unset. But that's fine actually.
If your package lists windowTypes, you *only* get loaded in those windowTypes. If you specify no windowTypes, you get loaded in the root window.
This means that onboarding, worker-ui, worker-sync, etc. no longer get loaded into the main window
ActivitySidebar has a special little store that observes the task queue since it's no longer in the window
Move "toggle component regions" / "toggle react remote" to the Developer menu
Move sync worker specs, update draft store specs to not rely on TaskQueue at all
Test Plan: Run existing tests, all pass
Reviewers: dillon, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1936
