fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
Message = require '../../src/flux/models/message'
|
2015-09-26 04:16:54 +08:00
|
|
|
Actions = require '../../src/flux/actions'
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
DatabaseStore = require '../../src/flux/stores/database-store'
|
2015-12-18 03:46:05 +08:00
|
|
|
DatabaseTransaction = require '../../src/flux/stores/database-transaction'
|
2016-04-20 07:08:58 +08:00
|
|
|
DraftEditingSession = require '../../src/flux/stores/draft-editing-session'
|
|
|
|
DraftChangeSet = DraftEditingSession.DraftChangeSet
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
_ = require 'underscore'
|
|
|
|
|
|
|
|
describe "DraftChangeSet", ->
|
|
|
|
beforeEach ->
|
|
|
|
@triggerSpy = jasmine.createSpy('trigger')
|
|
|
|
@commitResolve = null
|
|
|
|
@commitResolves = []
|
|
|
|
@commitSpy = jasmine.createSpy('commit').andCallFake =>
|
|
|
|
new Promise (resolve, reject) =>
|
|
|
|
@commitResolves.push(resolve)
|
|
|
|
@commitResolve = resolve
|
|
|
|
|
|
|
|
@changeSet = new DraftChangeSet(@triggerSpy, @commitSpy)
|
|
|
|
@changeSet._pending =
|
|
|
|
subject: 'Change to subject line'
|
|
|
|
|
|
|
|
describe "teardown", ->
|
|
|
|
it "should remove all of the pending and saving changes", ->
|
|
|
|
@changeSet.teardown()
|
|
|
|
expect(@changeSet._saving).toEqual({})
|
|
|
|
expect(@changeSet._pending).toEqual({})
|
|
|
|
|
|
|
|
describe "add", ->
|
|
|
|
it "should mark that the draft is not pristine", ->
|
|
|
|
@changeSet.add(body: 'Hello World!')
|
|
|
|
expect(@changeSet._pending.pristine).toEqual(false)
|
|
|
|
|
|
|
|
it "should add the changes to the _pending set", ->
|
|
|
|
@changeSet.add(body: 'Hello World!')
|
|
|
|
expect(@changeSet._pending.body).toEqual('Hello World!')
|
|
|
|
|
|
|
|
describe "otherwise", ->
|
2015-10-29 07:51:46 +08:00
|
|
|
it "should commit after thirty seconds", ->
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
spyOn(@changeSet, 'commit')
|
|
|
|
@changeSet.add({body: 'Hello World!'})
|
|
|
|
expect(@changeSet.commit).not.toHaveBeenCalled()
|
2015-10-29 07:51:46 +08:00
|
|
|
advanceClock(31000)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
expect(@changeSet.commit).toHaveBeenCalled()
|
|
|
|
|
|
|
|
describe "commit", ->
|
|
|
|
it "should resolve immediately if the pending set is empty", ->
|
|
|
|
@changeSet._pending = {}
|
|
|
|
waitsForPromise =>
|
|
|
|
@changeSet.commit().then =>
|
|
|
|
expect(@commitSpy).not.toHaveBeenCalled()
|
|
|
|
|
|
|
|
it "should move changes to the saving set", ->
|
|
|
|
pendingBefore = _.extend({}, @changeSet._pending)
|
|
|
|
expect(@changeSet._saving).toEqual({})
|
|
|
|
@changeSet.commit()
|
|
|
|
advanceClock()
|
|
|
|
expect(@changeSet._pending).toEqual({})
|
|
|
|
expect(@changeSet._saving).toEqual(pendingBefore)
|
|
|
|
|
|
|
|
it "should call the commit handler and then clear the saving set", ->
|
|
|
|
@changeSet.commit()
|
|
|
|
advanceClock()
|
|
|
|
expect(@changeSet._saving).not.toEqual({})
|
|
|
|
@commitResolve()
|
|
|
|
advanceClock()
|
|
|
|
expect(@changeSet._saving).toEqual({})
|
|
|
|
|
|
|
|
describe "concurrency", ->
|
|
|
|
it "the commit function should always run serially", ->
|
|
|
|
firstFulfilled = false
|
|
|
|
secondFulfilled = false
|
|
|
|
|
|
|
|
@changeSet._pending = {subject: 'A'}
|
|
|
|
@changeSet.commit().then =>
|
|
|
|
@changeSet._pending = {subject: 'B'}
|
|
|
|
firstFulfilled = true
|
|
|
|
@changeSet.commit().then =>
|
|
|
|
secondFulfilled = true
|
|
|
|
|
|
|
|
advanceClock()
|
|
|
|
expect(firstFulfilled).toBe(false)
|
|
|
|
expect(secondFulfilled).toBe(false)
|
|
|
|
@commitResolves[0]()
|
|
|
|
advanceClock()
|
|
|
|
expect(firstFulfilled).toBe(true)
|
|
|
|
expect(secondFulfilled).toBe(false)
|
|
|
|
@commitResolves[1]()
|
|
|
|
advanceClock()
|
|
|
|
expect(firstFulfilled).toBe(true)
|
|
|
|
expect(secondFulfilled).toBe(true)
|
|
|
|
|
|
|
|
describe "applyToModel", ->
|
|
|
|
it "should apply the saving and then the pending change sets, in that order", ->
|
|
|
|
@changeSet._saving = {subject: 'A', body: 'Basketb'}
|
|
|
|
@changeSet._pending = {body: 'Basketball'}
|
|
|
|
m = new Message()
|
|
|
|
@changeSet.applyToModel(m)
|
|
|
|
expect(m.subject).toEqual('A')
|
|
|
|
expect(m.body).toEqual('Basketball')
|
|
|
|
|
2016-04-20 07:08:58 +08:00
|
|
|
describe "DraftEditingSession", ->
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
describe "constructor", ->
|
|
|
|
it "should make a query to fetch the draft", ->
|
|
|
|
spyOn(DatabaseStore, 'run').andCallFake =>
|
|
|
|
new Promise (resolve, reject) =>
|
2016-04-20 07:08:58 +08:00
|
|
|
session = new DraftEditingSession('client-id')
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
expect(DatabaseStore.run).toHaveBeenCalled()
|
|
|
|
|
|
|
|
describe "when given a draft object", ->
|
|
|
|
beforeEach ->
|
|
|
|
spyOn(DatabaseStore, 'run')
|
|
|
|
@draft = new Message(draft: true, body: '123')
|
2016-04-20 07:08:58 +08:00
|
|
|
@session = new DraftEditingSession('client-id', @draft)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
it "should not make a query for the draft", ->
|
|
|
|
expect(DatabaseStore.run).not.toHaveBeenCalled()
|
|
|
|
|
2016-03-17 10:27:12 +08:00
|
|
|
it "prepare should resolve without querying for the draft", ->
|
2016-04-20 07:08:58 +08:00
|
|
|
waitsForPromise => @session.prepare().then =>
|
|
|
|
expect(@session.draft()).toBeDefined()
|
2016-03-17 10:27:12 +08:00
|
|
|
expect(DatabaseStore.run).not.toHaveBeenCalled()
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
describe "teardown", ->
|
|
|
|
it "should mark the session as destroyed", ->
|
2016-04-20 07:08:58 +08:00
|
|
|
spyOn(DraftEditingSession.prototype, "prepare")
|
|
|
|
session = new DraftEditingSession('client-id')
|
|
|
|
session.teardown()
|
|
|
|
expect(session._destroyed).toEqual(true)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
describe "prepare", ->
|
|
|
|
beforeEach ->
|
|
|
|
@draft = new Message(draft: true, body: '123', clientId: 'client-id')
|
2016-04-20 07:08:58 +08:00
|
|
|
spyOn(DraftEditingSession.prototype, "prepare")
|
|
|
|
@session = new DraftEditingSession('client-id')
|
|
|
|
spyOn(@session, '_setDraft').andCallThrough()
|
feat(tasks): add Create, Update, Destroy tasks plus spec & lint fixes
Summary:
1. **Generic CUD Tasks**: There is now a generic `CreateModelTask`,
`UpdateModelTask`, and `DestroyModelTask`. These can either be used as-is
or trivially overridden to easily update simple objects. Hopefully all of
the boilerplate rollback, error handling, and undo logic won't have to be
re-duplicated on every task. There are also tests for these tasks. We use
them to perform mutating actions on `Metadata` objects.
1. **Failing on Promise Rejects**: Turns out that if a Promise rejected
due to an error or `Promise.reject` we were ignoring it and letting tests
pass. Now, tests will Fail if any unhandled promise rejects. This
uncovered a variety of errors throughout the test suite that had to be
fixed. The most significant one was during the `theme-manager` tests when
all packages (and their stores with async DB requests) was loaded. Long
after the `theme-manager` specs finished, those DB requests were
(somtimes) silently failing.
1. **Globally stub `DatabaseStore._query`**: All tests shouldn't actually
make queries on the database. Furthremore, the `inTransaction` block
doesn't resolve at all unless `_query` is stubbed. Instead of manually
remembering to do this in every test that touches the DB, it's now mocked
in `spec_helper`. This broke a handful of tests that needed to be manually
fixed.
1. **ESLint Fixes**: Some minor fixes to the linter config to prevent
yelling about minor ES6 things and ensuring we have the correct parser.
Test Plan: new tests
Reviewers: bengotow, juan, drew
Differential Revision: https://phab.nylas.com/D2419
Remove cloudState and N1-Send-Later
2016-01-05 08:39:14 +08:00
|
|
|
spyOn(DatabaseStore, 'run').andCallFake (modelQuery) =>
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
Promise.resolve(@draft)
|
2016-04-20 07:08:58 +08:00
|
|
|
jasmine.unspy(DraftEditingSession.prototype, "prepare")
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
it "should call setDraft with the retrieved draft", ->
|
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.prepare().then =>
|
|
|
|
expect(@session._setDraft).toHaveBeenCalledWith(@draft)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
2016-04-20 07:08:58 +08:00
|
|
|
it "should resolve with the DraftEditingSession", ->
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.prepare().then (val) =>
|
|
|
|
expect(val).toBe(@session)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
describe "error handling", ->
|
|
|
|
it "should reject if the draft session has already been destroyed", ->
|
2016-04-20 07:08:58 +08:00
|
|
|
@session._destroyed = true
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.prepare().then =>
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
expect(false).toBe(true)
|
|
|
|
.catch (val) =>
|
|
|
|
expect(val instanceof Error).toBe(true)
|
|
|
|
|
|
|
|
it "should reject if the draft cannot be found", ->
|
|
|
|
@draft = null
|
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.prepare().then =>
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
expect(false).toBe(true)
|
|
|
|
.catch (val) =>
|
|
|
|
expect(val instanceof Error).toBe(true)
|
|
|
|
|
|
|
|
describe "when a draft changes", ->
|
|
|
|
beforeEach ->
|
|
|
|
@draft = new Message(draft: true, clientId: 'client-id', body: 'A', subject: 'initial')
|
2016-04-20 07:08:58 +08:00
|
|
|
@session = new DraftEditingSession('client-id', @draft)
|
2016-03-17 10:27:12 +08:00
|
|
|
advanceClock()
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
2015-12-18 03:46:05 +08:00
|
|
|
spyOn(DatabaseTransaction.prototype, "persistModel").andReturn Promise.resolve()
|
2015-09-26 04:16:54 +08:00
|
|
|
spyOn(Actions, "queueTask").andReturn Promise.resolve()
|
|
|
|
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
it "should ignore the update unless it applies to the current draft", ->
|
2016-04-20 07:08:58 +08:00
|
|
|
spyOn(@session, 'trigger')
|
|
|
|
@session._onDraftChanged(objectClass: 'message', objects: [new Message()])
|
|
|
|
expect(@session.trigger).not.toHaveBeenCalled()
|
|
|
|
@session._onDraftChanged(objectClass: 'message', objects: [@draft])
|
|
|
|
expect(@session.trigger).toHaveBeenCalled()
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
it "should apply the update to the current draft", ->
|
|
|
|
updatedDraft = @draft.clone()
|
|
|
|
updatedDraft.subject = 'This is the new subject'
|
|
|
|
|
2016-04-20 07:08:58 +08:00
|
|
|
@session._onDraftChanged(objectClass: 'message', objects: [updatedDraft])
|
|
|
|
expect(@session.draft().subject).toEqual(updatedDraft.subject)
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
2015-09-26 04:16:54 +08:00
|
|
|
it "atomically commits changes", ->
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
spyOn(DatabaseStore, "run").andReturn(Promise.resolve(@draft))
|
2015-12-18 03:46:05 +08:00
|
|
|
spyOn(DatabaseStore, 'inTransaction').andCallThrough()
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.add({body: "123"})
|
2015-09-26 04:16:54 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.commit().then =>
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(DatabaseStore.inTransaction).toHaveBeenCalled()
|
|
|
|
expect(DatabaseStore.inTransaction.calls.length).toBe 1
|
2015-09-26 04:16:54 +08:00
|
|
|
|
|
|
|
it "persist the applied changes", ->
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
spyOn(DatabaseStore, "run").andReturn(Promise.resolve(@draft))
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.add({body: "123"})
|
2015-09-26 04:16:54 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.commit().then =>
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(DatabaseTransaction.prototype.persistModel).toHaveBeenCalled()
|
|
|
|
updated = DatabaseTransaction.prototype.persistModel.calls[0].args[0]
|
2015-09-26 04:16:54 +08:00
|
|
|
expect(updated.body).toBe "123"
|
|
|
|
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
# Note: Syncback temporarily disabled
|
|
|
|
#
|
|
|
|
# it "queues a SyncbackDraftTask", ->
|
|
|
|
# spyOn(DatabaseStore, "run").andReturn(Promise.resolve(@draft))
|
2016-04-20 07:08:58 +08:00
|
|
|
# @session.changes.add({body: "123"})
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
# waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
# @session.changes.commit().then =>
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
# expect(Actions.queueTask).toHaveBeenCalled()
|
|
|
|
# task = Actions.queueTask.calls[0].args[0]
|
|
|
|
# expect(task.draftClientId).toBe "client-id"
|
2015-09-26 04:16:54 +08:00
|
|
|
|
2015-12-22 03:50:52 +08:00
|
|
|
it "doesn't queues a SyncbackDraftTask if no Syncback is passed", ->
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
spyOn(DatabaseStore, "run").andReturn(Promise.resolve(@draft))
|
2015-12-22 03:50:52 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.commit({noSyncback: true}).then =>
|
2015-12-22 03:50:52 +08:00
|
|
|
expect(Actions.queueTask).not.toHaveBeenCalled()
|
|
|
|
|
2015-09-26 04:16:54 +08:00
|
|
|
describe "when findBy does not return a draft", ->
|
|
|
|
it "continues and persists it's local draft reference, so it is resaved and draft editing can continue", ->
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
spyOn(DatabaseStore, "run").andReturn(Promise.resolve(null))
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.add({body: "123"})
|
2015-09-26 04:16:54 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session.changes.commit().then =>
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(DatabaseTransaction.prototype.persistModel).toHaveBeenCalled()
|
|
|
|
updated = DatabaseTransaction.prototype.persistModel.calls[0].args[0]
|
2015-09-26 04:16:54 +08:00
|
|
|
expect(updated.body).toBe "123"
|
|
|
|
|
|
|
|
it "does nothing if the draft is marked as destroyed", ->
|
patch(save): Only save drafts when necessary, avoid sync-engine issues
Summary:
Previously, we have saved drafts back to the user's provider through the sync engine. There are a handful of very serious edge case issues we're working to solve that are creating a bad user experience. (#933, #1175, #1504, #1237)
For now, we're going to change the behavior of N1 to mitagate these issues.
- If you create a draft in N1, we will not sync it to other mail clients while you're working on it.
- If you enable send later, we'll start syncing the draft to the server as before.
- If you created the draft in another client, we'll sync the draft to the server as before.
Fix specs
Test Plan: Run specs
Reviewers: evan, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D2706
2016-03-11 03:03:38 +08:00
|
|
|
spyOn(DatabaseStore, "run").andReturn(Promise.resolve(@draft))
|
2015-12-18 03:46:05 +08:00
|
|
|
spyOn(DatabaseStore, 'inTransaction').andCallThrough()
|
2015-09-26 04:16:54 +08:00
|
|
|
waitsForPromise =>
|
2016-04-20 07:08:58 +08:00
|
|
|
@session._destroyed = true
|
|
|
|
@session.changes.add({body: "123"})
|
|
|
|
@session.changes.commit().then =>
|
2015-12-18 03:46:05 +08:00
|
|
|
expect(DatabaseStore.inTransaction).not.toHaveBeenCalled()
|
2015-09-26 04:16:54 +08:00
|
|
|
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
describe "draft pristine body", ->
|
|
|
|
describe "when the draft given to the session is pristine", ->
|
|
|
|
it "should return the initial body", ->
|
|
|
|
pristineDraft = new Message(draft: true, body: 'Hiya', pristine: true, clientId: 'client-id')
|
|
|
|
updatedDraft = pristineDraft.clone()
|
|
|
|
updatedDraft.body = '123444'
|
|
|
|
updatedDraft.pristine = false
|
|
|
|
|
2016-04-20 07:08:58 +08:00
|
|
|
@session = new DraftEditingSession('client-id', pristineDraft)
|
|
|
|
@session._onDraftChanged(objectClass: 'message', objects: [updatedDraft])
|
|
|
|
expect(@session.draftPristineBody()).toBe('Hiya')
|
fix(drafts): If a draft disappears during editing, re-save instead of blowing up (Sentry 2844, more.)
Summary:
Previously, if a draft was deleted while a DraftChangeSet had uncommitted changes, it would blow up trying to find the draft.
This is bad, and can happen in normal scenarios. There are several changes in this diff:
- The DraftChangeSet no longer retrieves the draft from the database before saving changes. Instead, the save logic is in the DraftStoreProxy which already has a version of the draft kept fresh by a subscription to the DraftStore.
- The SyncbackDraftTask already had logic for POSTing when a PUT to a draft returns a 404, so no new logic was necessary there. THe new "commit" logic causes us to put back the draft that was lost, and then when we save it we detatch it from it's serverId and re-save.
In manual testing, this transparently handles the case where you delete a draft from Gmail while editing it.
Test Plan: I've added 22 tests for the DraftChangeSet and DraftStoreProxy
Reviewers: dillon, evan
Reviewed By: dillon, evan
Differential Revision: https://phab.nylas.com/D2012
2015-09-15 02:30:16 +08:00
|
|
|
|
|
|
|
describe "when the draft given to the session is not pristine", ->
|
|
|
|
it "should return null", ->
|
|
|
|
dirtyDraft = new Message(draft: true, body: 'Hiya', pristine: false)
|
2016-04-20 07:08:58 +08:00
|
|
|
@session = new DraftEditingSession('client-id', dirtyDraft)
|
|
|
|
expect(@session.draftPristineBody()).toBe(null)
|