Summary: See diff title
Test Plan: Run locally, verify that we backoff on failure
Reviewers: evan, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3887
Summary:
Fixes T7832
The _savePromise mechanism of the IdentityStore was really cumbersome and
was throwing errors on the console for people. In hindsight, this is an
unnecessary complication to a very sensitive system and a source of very
hairy async bugs.
Test Plan:
I also updated the specs to ensure that when you call saveIdentity the
promise resolves after the local cache has been updated
Reviewers: spang, halla, juan
Reviewed By: juan
Maniphest Tasks: T7832
Differential Revision: https://phab.nylas.com/D3882
Summary:
The app regressed to launching a blank white page for a while before
showing the UI. This was because I forgot to await for the now async
package loading
Test Plan: Manually boot app with compile cache disabled
Reviewers: mark, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3883
Summary:
Previously, these tests were mostly testing the library itself, instead
of our code. The library performed expensive operations and caused the
test to time out more often than not
This commit makes it so we test our code, mock out any calls to side
effects, and removes a line that was overriding our jasmine timeout
Test Plan: unit
Reviewers: spang, evan, halla
Reviewed By: evan, halla
Differential Revision: https://phab.nylas.com/D3885
Summary:
This notification was randomly appearing and not going away on its own.
This was due to some weird logic in the react component. This diff
refactors things to make them a little more consistent.
Test Plan:
Run locally, disconnecting and reconnecting to make sure we properly
show and hide the notification.
Reviewers: evan, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3881
Summary:
This commit modifies the api of NylasAPIRequest to /not/ take `success`
or `error` callback options at all, and only returns a Promise which you
can `then` and `catch` to handle the api response.
The fact that it returned a promise, and /also/ took `success` and
`error` callback options made it really confusing to use.
Additionaly, when using the callbacks intead of a promise, any errors
would be unhandled and reported to Sentry because even though the `error`
callback was being passed, the promise returned by `run()` still rejected and
no one was handling that reject, so it reached the `unhandledRejection` event
listener. This is undesirable because if you passed an `error` callback, it
means that you intended to handle it.
An example of this is calling the clearbit API, which will more often than
not return a 404, and even though we had an error handler which ignored the 404,
it still unecessarilly reported to Sentry, flooding it with events
Test Plan: manually check all updated codepaths still work
Reviewers: halla, spang, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3869
Summary:
During the _onDOMMutated callback, we disconnect the mutation observer,
call some other callbacks, and then reconnect the mutation observer. If
we threw an error during the callbacks before reconnect the mutation
observer we would never get any more callbacks when the user changed
things in the composer, causing us to stop saving updates to drafts
(among other things). The fix is to just make sure that we always
reconnect the mutation observer using a finally clause.
Test Plan:
Run locally, make sure drafts are no longer truncated after spelling
correction (which was triggering an error to be thrown)
Reviewers: juan, evan, spang
Reviewed By: spang
Differential Revision: https://phab.nylas.com/D3864
Summary:
This diff (and the K2 counterpart diff) allow us to run dev-mode Nylas
Mail side-by-side with prod Nylas Mail.
There were 4 things that needed to change:
1. Use different config dir
2. Use different keychain name
3. Use different localhost port
4. Prevent Electron's app.makeSingleInstance from killing our app
All of these are activated through NylasEnv.inDevMode()
Depends on D3861
Test Plan:
Download latest prod build from nylas.com
Remove both ~/.nylas-mail and ~/.nylas-dev
Start up downloaded Nylas Mail, connect accounts.
Run `npm start` (which enables --dev)
Connect account to dev mode
Ensure both clients are syncing and can send/receive mail
Reviewers: khamidou, halla, mark, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3862
Summary:
Snooze is back in the mainline but not yet ready for primetime. We need to not show the popover if it's not enabled, which is what this diff does. It should be pretty simple to revert it once snooze has officially shipped.
Fixes T7791.
Test Plan: Tested manually.
Reviewers: juan, evan
Reviewed By: evan
Maniphest Tasks: T7791
Differential Revision: https://phab.nylas.com/D3855
Summary:
This adds the "You've reached max features" modal in N1.
http://g.recordit.co/9O7R0mLlXE.gif
Test Plan:
1. Pull latest nylas/cloud-core and start Billing site:
```
cd cloud-core
vagrant up
vagrant ssh
cd /vagrant
bin/setup-up-feature-usage
bin/launch
```
2. Blow away ~/.nylas-mail (err backup your old one first)
3. Restart N1
4. Before logging in, edit `~/.nylas-mail/config.json`
- set env to "local"
- remove `thread-snooze` from the list of `disabledPlugins`
5. `cd /nylas-mail/src/k2` and run `npm start`
6. Restart N1 and create accounts & log in
Reviewers: khamidou, juan, halla
Reviewed By: halla
Differential Revision: https://phab.nylas.com/D3846
Summary:
FTS tables don't support indices, so doing UPDATEs and DELETEs based on
the `content_id` was very slow on large FTS tables. Fortunately, it seems
that `UPDATE`s and `DELETE`s based on the `rowid` are much faster, so now we
store that info hanging off the searchable models. Also fixes a random bug
where after reaching the `MAX_INDEX_SIZE` we would clear the Thread search
index on startup.
Test Plan: Run locally, time how long it takes to delete when receiving new mail
Reviewers: spang, evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D3847
Summary:
It's slow, so only do it if we've never seen the Account before. This
fixes jank that would happen somewhat randomly. It was especially noticeable
if the user had a lot of Accounts (and therefore a lot of passwords to
load).
Test Plan: Run locally, verify that we only load new Accounts
Reviewers: spang, evan, juan
Reviewed By: evan, juan
Maniphest Tasks: T7766
Differential Revision: https://phab.nylas.com/D3848