Summary:
This commit makes it so `resetEmailCache` works as expected, i.e. it
removes all databases, without forcing the user to re sign-in to their
accounts or NylasID

Previously, this method removed the database without removing the
accounts, left users in an un-authed state that was hard to recover
from. This was fixed in D4212 which makes sure that when we get a new
identity, sync and deltas are restarted

However, resetEmailCache would still force you to log in to yoru NylasID
because it was deleted from the database. However, if we reuse the
command `application:relaunch-to-initial-windows` instead of manually
deleting the database, we can relaunc the app while preserving the users
NylasID session, so they don't have to sign back in manually.

Test Plan: manual

Reviewers: evan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4215

Summary:
Use electron's `powerMonitor` module to detect when the computer resumes
from sleep, and restart the sync loop when that happens in order to
sync the inbox immediately, in case we received any new mail events
while the computer was asleep

Test Plan: manual

Reviewers: evan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4216

Summary:
On windows running `git rev-parse --short HEAD` does in fact now give you
9 characters instead of 7 like it does on Mac. This will ensure that
builds get uploaded to the same folder and help ensure we don't post a
version that doesn't exist on the release page.

Test Plan: Manual

Reviewers: juan, halla, spang

Reviewed By: spang

Differential Revision: https://phab.nylas.com/D4217

Summary: Minor copy change via Sachin

Test Plan: manual

Reviewers: juan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4218

Summary:
This is going to be a diff way shorter than the previous one! Basically, it adds a new endpoint, `/blobs` to our API to store send later attachments. When a user schedules a draft to be sent, we send all attachments to this endpoint. Separately, we store the rest of the message as metadata.

When it's time to send the message, we fetch the attachments from S3, fetch the metadata and merge them together to get a message we can send.

Test Plan: Tested manually. Will make a final QA pass before landing.

Reviewers: juan, halla, evan

Reviewed By: halla, evan

Differential Revision: https://phab.nylas.com/D4196

Summary: We need to upload the nupkg for the Windows autoupdater to work

Test Plan: manual

Reviewers: juan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4219

Summary:
The ignore list was very old. It included several dozen MB of docs_src and
other crap in our builds

Test Plan: manual

Reviewers: halla, spang, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4213

Summary:
We don't need to spend the time running script/bootstrap in our cloud-*
folders!

Test Plan: manual

Reviewers: spang, juan, halla

Reviewed By: juan, halla

Differential Revision: https://phab.nylas.com/D4214

Summary:
We were using a version that was ~9 months old and a lot of development has
happened since.

v3 is not compatible w/v2, but it looks like we aren't using any of the
features that had breaking changes:

    http://nodemailer.com/about/migrate/

I chose not to switch to the new built-in OAuth2 token refresh support
because we already have a mechanism for refreshing oauth tokens and
adding a different implementation specifically for SMTP would introduce
more opportunities for bugs.

Since mailcomposer is no longer a dependency of nodemailer, I added this
dependency as well.

Test Plan: manual - sent a message, sent a message w/an attachment

Reviewers: evan, khamidou, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4201

…y received

Summary:
We don't want to bump threads to the top of the inbox when a user sends a
reply. We originally used `!isSent` to prevent this, but that was removed in
a diff that made sure messages showed up in the inbox when users send emails
to themselves. In order to implement both of these cases properly, this diff
introduces `isReceived` and uses that to determine whether lastReceivedDate
should be updated. Addresses T7991.

Also changes the order of some `or` statements, so that we actually check that
the variable exists before comparing against it.

Test Plan: manual

Reviewers: evan, juan, spang

Reviewed By: spang

Differential Revision: https://phab.nylas.com/D4226

Summary:
Previously, after creating a new folder, the UI would indicate that the new
folder had children, even though it didn't. This was caused by duplicate models
in our `MutableQueryResultSet` for the user's categories. Basically, we would
sync the server version of the folder before the `SyncbackTask` for the new
folder returned its `serverId`. Without the `serverId`, the synced version of
the folder couldn't yet be tied to the optimistic folder, so a second row was
created in the database. This second row is removed when the `syncbackTask`
does return the `serverId`, because we persist the optimistic folder with a
`REPLACE INTO` query. (This deletes other rows with the same id.) However,
since this was done inside a `persist` change with the `serverId` and no
`unpersist` was ever recorded for the `clientId`, our `MutableQueryResultSet`
never removed the `clientId` model.

To address this, this diff adds a check in `updateModel` to see if the
`serverId` is being added. If it is, and both the `serverId` and `clientId`
exist in the `_ids` list, we remove the `clientId`.

The children indicator does still briefly show up while there are still two
separate rows for that folder in the database. If we want to get rid of this
completely, we would have to ensure that we do not sync the folder before the
`syncbackTask` returns the `serverId`. However, this would probably be pretty
involved, and for not much gain. This fix is much simpler and reduces most of
the issue.

Test Plan: manual

Reviewers: juan, evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D4228

This reverts commit e798e50.

Reason for revert: breaks Send Later. Needs more testing.

Summary: see title. also convert to es6

Test Plan: manual

Reviewers: evan, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4225

for ei-prod only.  I set up the ei EB env as prod level, but
have been working on launch changed in master branch. Easy enough to undo,
but I didn't wan't to mess with prod branch until done because
the launch scripts affect all the n1cloud-related environments.

Summary:
When querying transactions for the delta stream, if no cursor is provided,
we should default to 0. Otherwise this will generate a query like:
```
WHERE `transaction`.`id` > ‘null’
```
Which is obviously wrong

Test Plan: manual

Reviewers: evan, halla, spang

Reviewed By: spang

Differential Revision: https://phab.nylas.com/D4242

Summary:
Currently, when we auth an account for the first time in Nylas Mail (or
we blow away the database), the app is going to request transactions
since cursor `null` from the /delta/streaming endpoint and from the local-sync
delta observable, instead of requesting transactions since cursor `0`

This is due to a subtle bug with the use of default values when
destructuring an object. Our coded did the following:
```
const {cursor = 0} = this._state
```
Which at a glance seems correct. However, this will only work as
expected if `this._state` has the following shape:
```
{cursor: undefined}
```
And unfortunately, our `this._state` looked like this when authing an
account for the first time:
```
{cursor: null}
```

Which would make `cursor === null` instead of `0`.
This is because when using default values, null is considered an
intentional argument/value, as opposed to not passing any argument/value
(which will mean that the argument is undefined).

This was a regression introduced in d60a23c and 8bc2ec5

Test Plan: manual, will add regression test in upcoming diff

Reviewers: evan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4243

Summary:
Previously, the logic for deciding wether to report an APIError lived
inside NylasAPIRequest and depended on an array of ignorable
statusCodes. However, when handling APIErrors, NylasAPIRequest would
convert special error codes (for offline errors) into a statusCode of 0,
which would automatically be ignored.

Given that the delta streaming connection didn't convert status codes to
0, it wouldn't actually ignore the error and end up reporting it,
flooding sentry.

This commit makes it so that that logic lives inside APIError, and
anyone who handles APIErrors can check wether to report them or not,
including the delta streaming connection

Test Plan: manual :(

Reviewers: spang, evan, halla

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D4235

Summary:
This fixes T7995.

Previously, attempting to log out from your NylasID would just
automatically sign you back in with the same NylasID because the webview
session was preserved.

Now, instead of relaunching the windows, we restart the app to clear the
webview session

Test Plan: manual

Reviewers: halla, evan

Reviewed By: evan

Maniphest Tasks: T7995

Differential Revision: https://phab.nylas.com/D4224

Summary: In preparation for removing timeout handling from the IMAPConnectionPool.

Test Plan: Run locally

Reviewers: spang, evan, juan

Reviewed By: evan, juan

Differential Revision: https://phab.nylas.com/D4245

Summary: Using `await` instead of `advanceClock()` fixes all the things!

Test Plan: Ran the spec file

Reviewers: evan, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4248

On the server the env var is defined but set to false.

Summary:
Found a funny send-later bug I didn't catch when testing on staging: sometimes the data we're saving in the metadata table overflows. That's because MySQL's TEXT column are at most 64k, which is easy to reach when you have a draft + clearbit information and additional stuff.

To work around this, I decided to switch the database type of the metadata table to LONGTEXT. Since it can store 4Gb of text, we should be good. This diff makes those code changes. Obviously, we'll have to run migrations both on staging and prod.

Test Plan: Ran a basic smoke test. Shouldn't break anything.

Reviewers: juan, evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D4250

Summary:
We need to download the files and then treat them as uploads. Rather
than using an actual Upload object, which would require another data
transfer, we create an object with all the necessary Upload-like
properties and point it to the downloaded file.

Addresses part of T7960

Test Plan: Manual, some specs

Reviewers: evan, spang, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4249

Summary:
The original name seems like it's initiating the download, when really
it's just returning the data of an already in-progress/completed
download.

Test Plan: Manual, specs

Reviewers: evan, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4251

Summary:
We'd like to get an idea of how long the client app is having to wait
when requesting a file. Waiting can cause things like inline image
attachments to appear very slow to load.

Test Plan: Run locally

Reviewers: evan, spang, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4255

Summary:
Different clients can have different policies for retrying after
timeouts.

Test Plan: Run locally, run tests

Reviewers: evan, spang, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4247

Summary: See title

Test Plan: manual

Reviewers: gleb, mark

Reviewed By: mark

Differential Revision: https://phab.nylas.com/D4256

…rter

Summary:
I had a bit of downtime this morning so I decided to look into how to store Electron crash data. Electron, like Chromium, stores crash data in an arcane file format named minidump.

There's a bunch of services you can use to store files formatted in this format, like Mozilla's Socorro or zcbenz's own mini-breakpad-server but they're all pretty hard to install. Luckily, it turns out there's a Ruby gem to process minidump files and send them to Sentry! Seeing that, I whipped up a quick sinatra service and hosted it on Heroku – you can take a look at the source code here if you're curious: https://github.com/khamidou/electron-breakpad-sentry

This diff adds the client-side code we need to start sending crash reports.

Test Plan: Tested manually.

Reviewers: juan, evan

Reviewed By: juan, evan

Maniphest Tasks: T7926

Differential Revision: https://phab.nylas.com/D4259

Summary:
Before this commit, it was impossible to remove inline images via the x
button

Test Plan: manual

Reviewers: mark, halla

Reviewed By: mark, halla

Differential Revision: https://phab.nylas.com/D4257

Summary:
The IdentityStore can trigger any number of times, but we only want to
start sync if we previously didn't have an identity available

Test Plan: manual

Reviewers: spang, evan, halla

Reviewed By: evan, halla

Differential Revision: https://phab.nylas.com/D4246

Summary:
We weren't doing that, so we would have accurate search index info for
threads when they were, e.g., moved to another folder.

Test Plan: Run locally

Reviewers: spang, evan, juan

Reviewed By: evan, juan

Differential Revision: https://phab.nylas.com/D4260

Summary:
These only really matter for n1cloud, and are being added manually in
production, so no migration file necessary. I am adding them to the
model definitions to prevent them getting out of sync with production
for development.

See T7999 for full SQL review

Test Plan: ship it

Reviewers: evan, khamidou, juan

Reviewed By: juan

Subscribers: vlad, jerm

Differential Revision: https://phab.nylas.com/D4230

Summary: Should help a fair bit with our redis connection pileup.

Test Plan: Tested manually.

Reviewers: mark, spang, juan, evan

Reviewed By: mark, spang, evan

Differential Revision: https://phab.nylas.com/D3916

Summary:
We still don't know exactly what scenarios cause us to get 'database is
locked' errors, but generically this means that we have multiple
processes trying to access the database at the same time. In an attempt
to handle this gracefully, this diff makes it so that we retry the
queries in these cases. Theoretically, the database should free up once
the other process is done using it, and the erroring process just needs
to wait its turn. We still throw an error after 5 retries, so if there's
a larger issue, we'll still be able to tell in Sentry.

Addresses T7992

Test Plan:
I opened a transaction in the worker window and then tried to
do the same in the main window. If I didn't release the transaction in
the worker window, the main window eventually errored. If I did release
the transaction, the main window continued creating its own transaction.

Reviewers: mark, juan, evan

Reviewed By: juan, evan

Differential Revision: https://phab.nylas.com/D4254

Summary:
Add infrastructure to report and retrieve the latest sync activity, and
start reporting when we download a message or detect that a folder
has no new messages. This will be used to detect if the sync loop is
stuck. Part of T7681.

Test Plan: manual, specs

Reviewers: evan, mark, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4261

Summary:
Periodically check the latest sync activity times to determine if a sync
worker has been inactive for too long. If it has been too long, discard
the worker and create a new one for that account. Part of T7681.

Test Plan: manual, specs

Reviewers: evan, mark, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4262

Summary:
Periodically ping client-sync's /health endpoint and store the latest
sync activity. If we get an ECONNREFUSED error, the worker window is
unavailable. Report the last known activity and restart the worker
window. Part of T7681.

Test Plan: manual, specs

Reviewers: evan, mark, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4263

…indow

Summary: See title. Part of T7681.

Test Plan: ran the specs

Reviewers: evan, mark, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4264

Summary:
These locations will provide enough activity for monitoring and are also
more helpful in helping us debug what the sync loop was doing when it
got stuck.

Test Plan: manual

Reviewers: juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4274

In some places we were not accessing `.default` when using `require`,
and when using `import` we couldn't really destructure unless we
accessed `.default` too, or if the functions were regular exports
instead of properties on a default exported object.

This was causing our sync loop to error.

To remain consistent, we always just `require` or `import` the
SyncActivity singleton and access that

We were accessing `this._db.accountId` before `this._db` was set, which
caused an error when attempting to run the task

Summary:
Prior to Nylas Mail, the Nylas Cloud API provided an endpoint that
returned rankings for contacts which it computed based on how frequently
and how recently a user sent mail to a recipient. This diff reimplements
that functionality in Nylas Mail. This should improve contact
auto-complete when composing emails to frequently contacted recipients.

Test Plan: Run locally, verify that frequent contacts are suggested earlier

Reviewers: spang, evan, juan

Reviewed By: evan, juan

Maniphest Tasks: T7948

Differential Revision: https://phab.nylas.com/D4253

Summary:
We want to get to a usable inbox as quickly as possible, and throttling
prevents this. We should basically only be throttling for historical
mail syncing.

Test Plan: Run initial sync benchmark, it's 117% faster on battery

Reviewers: evan, juan, spang

Reviewed By: juan, spang

Differential Revision: https://phab.nylas.com/D4266

Summary:
This diff will give us insight into how people use Nylas Mail on their
computers with respect to how mobile they are (i.e. whether they use NM
on battery or plugged in).

Test Plan: Run locally

Reviewers: evan, spang, juan

Reviewed By: juan

Subscribers: gleb

Differential Revision: https://phab.nylas.com/D4267

Summary:
Sent mail is important for initial sync because it's used for contact
ranking. Prior to this diff we would delay syncing sent mail because we
would prioritize the inbox label over all other labels (including sent).
This diff includes the sent folder in the initial set of messages to sync.

Test Plan: Run locally, verify we get sent mail quickly

Reviewers: evan, spang, juan

Reviewed By: spang

Differential Revision: https://phab.nylas.com/D4268

Summary:
This commit makes it so postinstall.es6 only bootstraps the packages we
are interested in based on a new env variable, `INSTALL_TARGET`.

`INSTALL_TARGET` can be set to `cloud`, `client` or `all`, or not set at all,
and our postinstall will bootstrap the packages accordingly. This will make
build and deploy times faster.

Test Plan: manual

Reviewers: spang, halla, evan, khamidou

Reviewed By: evan, khamidou

Differential Revision: https://phab.nylas.com/D4271

Summary: See lovell/sharp#373 (comment)

Test Plan: manual

Reviewers: khamidou, evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D4273

Summary:
When using the IMAPConnectionPool in the sync-worker, we requested 2
connections from the pool: 1 to listen for new mail, and 1 to actually
operate on the mailbox. These 2 connections would be closed and returned
to the pool at the end of each sync loop iteration.

However, we never want to close the connection to listen for new mail.
Closing this connection caused us to not listen for new mail in between
sync loops, which was especially noticeable when initial sync was done
because the delay between sync loops is 5 minutes.

This commit makes it so we request the 2 connections separately from the
connection pool, and keep the listener connection always open until we
dispose of the sync-worker.

Test Plan:
manually make sure that I got new mail event listeners in between
sync loops :(

Reviewers: evan, spang, halla, mark

Reviewed By: mark

Differential Revision: https://phab.nylas.com/D4276

Summary:
This patch will prevent users from being able to connect accounts which sync
mail but fail to send.

This commit includes a couple pieces:
* Adds a call to nodemailer's `verify()` function in the /auth endpoint
* Adds Error object conversion for SMTP errors. Since we don't implement our
  own connection object or connection pool for SMTP, we simply wrap the couple
  places we call functions from nodemailer that connect to SMTP, namely
  SendmailClient's _send() and the new verify() call in /auth.
* Moves RetryableError to the 'errors' module since it's now a base class for
  retryable IMAP //and// SMTP errors.
* Moves the main `smtpConfig()` logic which used to live on the Account model
  into AuthHelpers so it can be shared between the Account model and the verify
  code.
* Converts a few different places to use `import` syntax instead of
  `require` syntax for module imports. Apologies for not splitting this out
  into a separate diff—would have been a fair amount of work and looks not too
  difficult to skim over in the context of the rest of the patch.
* Fixing a bug in a previous commit where erroring sends would crash because of
  using `this._transporter.options` instead of `this._transporter.transporter.options`

Test Plan: manual

Reviewers: evan, halla, juan

Reviewed By: halla, juan

Differential Revision: https://phab.nylas.com/D4200

Summary:
If `gmailInitialUIDsRemaining` was defined, we need to set `initialUids`
to that value. We were previously setting it to a key in
`folder.syncState` that didn't exist, which caused a runtime error.

This was introduced in https://github.com/nylas/nylas-mail-all/commit/d6a2b6935cddefb7ab8f4f99d6ce118fd6191aab

Test Plan: manual

Reviewers: spang, mark

Reviewed By: mark

Differential Revision: https://phab.nylas.com/D4279

…nches

…-api

Summary:
This prevented the /health endpoint from being available in the
local-api

Test Plan: manual

Reviewers: mark, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D4280

…erride

Summary:
By default, the 'local'/'development' environment assumes that all services
are running locally. This makes sense.

However, if you're not making changes to auxiliary services such as
billing.nylas.com and hence do not have them running locally, firing up
Nylas Mail with the 'local' env will not work. It's a bit of a pain to
get a local billing service running locally, especially if you're not
making any changes to that service. To ease development, change the
default billing URL during development to staging, and allow manually
overriding the billing server URL to point to localhost in the case
that you're making changes to the billing service also.

To override the billing URL for local development, run like this:

    npm run cloud -- --env billing_local
    BILLING_URL=http://billing.lvh.me:5555 npm start

This is both a problem that I've run into during development as well as
(my hunch) why Karim accidentally landed a global override of the
billing server URL.

Test Plan: manual

Reviewers: evan, khamidou, halla, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4202

This commit is the same as 7d409f5.

This commit was accidentally reverted in 95ec679, because I (juan) was being
dumb. So I'm re-committing here.

Summary:
We weren't doing that, so we would have accurate search index info for
threads when they were, e.g., moved to another folder.

Test Plan: Run locally

Reviewers: spang, evan, juan

Reviewed By: evan, juan

Differential Revision: https://phab.nylas.com/D4260

Summary:
Prior to this diff, the "in:" search query syntax didn't work for IMAP.
This diff implements "in:" by changing the IMAP search backend to take
folder context into account and emit the appropriate queries for each
folder. Queries that include "in:foo" will replace the corresponding AST
nodes with 'ALL' or 'NOT ALL' depending on whether or not the current folder
is "foo". We also now filter which folders we search based on which
folders are referenced in the query.

Test Plan: Run locally, verify that in: works quickly

Reviewers: evan, juan, spang

Reviewed By: juan, spang

Differential Revision: https://phab.nylas.com/D4284

Summary:
We weren't stripping link and open items from messages we sent properly.
While we stripped it from the first outgoing message, when the sync loop
came back around it would have them back in. This adds it in the message
processor to extra ensure that ANYTHING that comes from us (or one of our
aliases) gets the open/link tracking stripped

Test Plan: New tests

Reviewers: juan, halla

Reviewed By: juan, halla

Differential Revision: https://phab.nylas.com/D4287

Summary:
The problem actually was that we weren't applying the transform for Gmail
messages sent to 1 recipient

Test Plan: manual

Reviewers: halla, juan

Reviewed By: halla, juan

Differential Revision: https://phab.nylas.com/D4291

Summary:
After introducing retry logic, we would always defer db queries to the
next tick even if there was no retry delay present.

This would cause almost all db queries take more than 100ms even if the
actual db operation was really fast. This affected app performance
negatively

Test Plan: manual

Reviewers: evan, halla, mark

Reviewed By: halla, mark

Differential Revision: https://phab.nylas.com/D4282