Summary:
I've encountered random imap errors that we mark as permanent, but that
contain try again in the error message. We should check for that
Test Plan: manual
Reviewers: spang, evan, mark
Differential Revision: https://phab.nylas.com/D3899
Before this commit, running the running the tests would clear all of
your config inside `.nylas-dev` and thus your accounts, forcing you to re-add
them everytime after you ran the tests
This was happening because we weren't correctly setting the
`configDirPath` to `.nylas-spec` when running with the --test flag. When
we run with --test, both options, `specMode` and `devMode` are true, so
the logic to set the path would fall into both conditions and ultimately
set the path to `.nylas-dev`. Now it's fixed!
Summary:
The global `before/afterEach` functions were made async, but the
`masterBefore/AfterEach` functions were applied to the references
in `jasmineExports` instead of the global references. Fix that,
and await for `destroyTestDatabase()`. Also fix a random test
failure about not receiving any json.
This diff is necessary for D3878 to work properly.
Test Plan: ran the tests
Reviewers: juan, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3890
Summary: There's no file to unlink, we just need to drop the tables.
Test Plan: manual
Reviewers: evan, juan
Reviewed By: evan, juan
Differential Revision: https://phab.nylas.com/D3878
Summary:
If you have no messages in your Gmail Inbox (Yay Inbox Zero!) and you
connect your account and do first sync, then we get an error where we try
and fetch a range from null to -1.
This was due to a logical error in the first sync fetch code.
This diff fixes this bug and renames some variables to make it clearer
what's going on
Fixes T7842
{F11176}
Test Plan:
1. Bring Gmail to Inbox Zero
2. Connect account
3. Verify first sync works
Reviewers: spang, halla, juan
Reviewed By: juan
Maniphest Tasks: T7842
Differential Revision: https://phab.nylas.com/D3889
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: See diff title
Test Plan: Run locally, make sure we backoff
Reviewers: juan, spang, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3886
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:
Previously, when processing messages during folder sync, if the message already existed, and it belonged to a thread, we would update the message, but forget to update its thread with any changes that new
message would produce on the thread (e.g. updating the threads folders or labels).
One obvious manifestation of this was when replying to a thread: the EnsureMessageInSentFolderTask would create the new message, and then attempt to sync the sent folder to fetch the newly created message. When processing this message during sync, we would update the message but not update its thread, so the thread would not be associated to the sent folder, and it wouldn't show up in your sent items list in the UI.
Test Plan: manually verify that it works
Reviewers: evan, mark, spang
Reviewed By: mark, spang
Differential Revision: https://phab.nylas.com/D3872