Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2025-02-26 00:54:04 +08:00
Code Issues Projects Releases Packages Wiki Activity
💌 A beautiful, fast and fully open source mail client for Mac, Windows and Linux.
5567 commits 32 branches 69 tags 142 MiB
JavaScript 41.8%
TypeScript 28.8%
Fluent 14.4%
HTML 10.4%
Less 3.1%
Other 1.4%
Find a file
Juan Tejada 0f2896446e [client-sync] Bump sequelize version - Ensure it doesn't halt sync 
Summary:
This commit bumps the version of sequelize to point to the latest
version in our fork. This version bump also includes latest updates from
upstream sequelize since the last time we bumped the version.

Notably, it includes a critical fix that will prevent the sync
loop from getting stuck on rare occasions.

Specifically, sequelize's `Query.prototype.run` could in some cases return a
Promise that would /never/ resolve or reject, effectively halting the
execution of any code that was waiting for that promise. This was due to
a lack of error handling inside a the query's `afterExecute` function; if an
error was thrown there, the enclosing Promise would never reject, and
the error would just remain uncaught. An example of such an error that
could cause this scenario is: T7742 - https://sentry.io/nylas/nylas-mail/issues/230016155/

Sync getting halted in this way can produce a variety of user facing
bugs like not being able to send or it taking an absurd amount of time
(hours), tasks never finishing or taking an absurd amount of time to
complete, new mail not arriving, among others

The commit that fixes this is: 0deeda9e1a
The full set of changes introduced by this version bump are: https://github.com/nylas/sequelize/compare/nylas-3.30.0...nylas-3.40.0

**Note:**
It is important to note that sequelize might still halt the sync loop if
there are other places in the code that can return Promises that never
resolve or reject under certain circumstances. I can consistently reproduce this
scenario when an error is thrown inside `afterExecute`, and I've seen it
happen in the wild, but I've also ran into this type of sync loop halting (db
promises never resolve) without any sequelize errors being thrown, which
suggests that there are other places in the sequelize code that might end
up returning a Promise that will halt sync.

Unfortunately, we don't have a good way to detect and report when this
happens yet, but we are adding one in upcoming diffs in order have data
on how many people are running into this, and/or if this patch completely
fixes the issue. Otherwise, we'd need to audit sequelize's code.

Should resolve T7837 and T7767

Test Plan: manual

Reviewers: spang, mark, halla, khamidou, evan

Reviewed By: evan

Subscribers: mg, tomasz

Maniphest Tasks: T7767, T7837

Differential Revision: https://phab.nylas.com/D4152
2017-03-09 08:20:49 -08:00
.ebextensions Fixes to Docker and better docs/debugging 2017-01-03 09:32:08 -08:00
arclib
packages [client-sync] Bump sequelize version - Ensure it doesn't halt sync 2017-03-09 08:20:49 -08:00
scripts [none] (dev) Fix npm version bump path in script/daily 2017-03-08 22:32:47 -08:00
.arcconfig Update .arcconfig to point to new repo 2017-02-16 14:15:19 -08:00
.arclint [*] Temporary fix for coffee linter in arc lint 2017-02-17 16:21:47 -08:00
.babelrc [*] use hardlinked .babelrc for AppVeyor 2017-03-07 14:11:16 -05:00
.dockerignore [*] Make sure cloud deploy can access .babelrc 2017-02-22 12:09:14 -08:00
.eslintrc [none] Update .eslintrc 2017-03-01 16:57:03 -08:00
.gitignore [*] Change the symlink location for the isomorphic-core specs 2017-03-02 10:56:03 -08:00
.travis.yml [*] remove travs_wait now bootstrap more verbose 2017-03-06 14:13:12 -05:00
appveyor.yml [client-app] update appveyor 2017-03-03 14:22:38 -08:00
deploy-it [none] Make deploy-it support -h/--help 2017-02-28 15:42:23 -08:00
Dockerfile [dev, cloud-*] make Docker run plain npm install and conslidate deps 2017-02-21 14:33:00 -05:00
lerna.json [client-app] use forked lerna for better npm logging 2017-03-06 15:35:56 -05:00
package.json [none] (dev) Fix script name 2017-03-07 12:33:29 -08:00
README.md [*] update and add READMEs to each package 2017-02-17 17:28:09 -08:00

README.md

Nylas Mail

This is a collection of all components required to run Nylas Mail.

  1. Isomorphic Core: Shared code across local client and cloud servers
  2. Client App: The main Electron app for Nylas Mail mirrored to open source repo.
  3. Client Sync: The local mailsync engine integreated in Nylas Mail
  4. Client Private Plugins: Private Nylas Mail plugins (like SFDC)
  5. Cloud API: The cloud-based auth and metadata APIs for N1
  6. Cloud Core: Shared code used in all remote cloud services
  7. Cloud Workers: Cloud workers for services like send later

See /packages for the separate pieces. Each folder in /packages is designed to be its own stand-alone repository. They are all bundled here for the ease of source control management.

Initial Setup for All Local & Cloud Services:

New Computer (Mac):

  1. Install Homebrew
  2. Install NVM & Redis brew install nvm redis
  3. Install Node 6 via NVM: nvm install 6

New Computer (Linux - Debian/Ubuntu):

  1. Install Node 6+ via NodeSource (trusted):
  2. curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
  3. sudo apt-get install -y nodejs
  4. Install Redis locally sudo apt-get install -y redis-server redis-tools benefit of letting us use subdomains.

Running Nylas Mail

  1. npm install (Only on fresh install and new packages)
  2. npm run start-client: Starts Electron app client
  3. npm run start-cloud: Starts cloud API locally