2016-10-28 09:48:33 +08:00
|
|
|
Actions = require('../../src/flux/actions').default
|
2016-10-01 06:24:34 +08:00
|
|
|
DatabaseStore = require('../../src/flux/stores/database-store').default
|
2015-02-21 04:24:15 +08:00
|
|
|
TaskQueue = require '../../src/flux/stores/task-queue'
|
2016-05-04 07:42:28 +08:00
|
|
|
Task = require('../../src/flux/tasks/task').default
|
2017-06-23 06:07:04 +08:00
|
|
|
DatabaseObjectRegistry = require('../../src/registries/database-object-registry').default
|
2015-02-21 04:24:15 +08:00
|
|
|
|
2016-12-07 09:20:58 +08:00
|
|
|
{APIError} = require '../../src/flux/errors'
|
2015-02-21 04:24:15 +08:00
|
|
|
|
2016-05-20 03:33:03 +08:00
|
|
|
{TaskSubclassA,
|
|
|
|
|
TaskSubclassB,
|
|
|
|
|
KillsTaskA,
|
|
|
|
|
BlockedByTaskA,
|
|
|
|
|
BlockingTask,
|
|
|
|
|
TaskAA,
|
|
|
|
|
TaskBB} = require('./task-subclass')
|
2015-02-21 04:24:15 +08:00
|
|
|
|
fix(spec): add support for async specs and disable misbehaving ones
More spec fixes
replace process.nextTick with setTimeout(fn, 0) for specs
Also added an unspy in the afterEach
Temporarily disable specs
fix(spec): start fixing specs
Summary:
This is the WIP fix to our spec runner.
Several tests have been completely commented out that will require
substantially more work to fix. These have been added to our sprint
backlog.
Other tests have been fixed to update to new APIs or to deal with genuine
bugs that were introduced without our knowing!
The most common non-trivial change relates to observing the `NylasAPI` and
`NylasAPIRequest`. We used to observe the arguments to `makeRequest`.
Unfortunately `NylasAPIRequest.run` is argumentless. Instead you can do:
`NylasAPIRequest.prototype.run.mostRecentCall.object.options` to get the
`options` passed into the object. the `.object` property grabs the context
of the spy when it was last called.
Fixing these tests uncovered several concerning issues with our test
runner. I spent a while tracking down why our participant-text-field-spec
was failling every so often. I chose that spec because it was the first
spec to likely fail, thereby requiring looking at the least number of
preceding files. I tried binary searching, turning on and off, several
files beforehand only to realize that the failure rate was not determined
by a particular preceding test, but rather the existing and quantity of
preceding tests, AND the number of console.log statements I had. There is
some processor-dependent race condition going on that needs further
investigation.
I also discovered an issue with the file-download-spec. We were getting
errors about it accessing a file, which was very suspicious given the code
stubs out all fs access. This was caused due to a spec that called an
async function outside ot a `waitsForPromise` block or a `waitsFor` block.
The test completed, the spies were cleaned up, but the downstream async
chain was still running. By the time the async chain finished the runner
was already working on the next spec and the spies had been restored
(causing the real fs access to run).
Juan had an idea to kill the specs once one fails to prevent cascading
failures. I'll implement this in the next diff update
Test Plan: npm test
Reviewers: juan, halla, jackie
Differential Revision: https://phab.nylas.com/D3501
Disable other specs
Disable more broken specs
All specs turned off till passing state
Use async-safe versions of spec functions
Add async test spec
Remove unused package code
Remove canary spec
2016-12-13 04:12:20 +08:00
|
|
|
xdescribe "TaskQueue", ->
|
2015-05-20 03:07:08 +08:00
|
|
|
|
2015-02-21 04:24:15 +08:00
|
|
|
makeUnstartedTask = (task) ->
|
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks
Summary:
This diff does a couple things:
- Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable.
- NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request.
- Aborting a NylasAPI request now makes it call it's error callback / promise reject.
- You can now run code after perform local has completed using this syntax:
```
task = new AddRemoveTagsTask(focused, ['archive'], ['inbox'])
task.waitForPerformLocal().then ->
Actions.setFocus(collection: 'thread', item: nextFocus)
Actions.setCursorPosition(collection: 'thread', item: nextKeyboard)
Actions.queueTask(task)
```
- In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0).
- The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote".
- All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later.
- API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish.
- The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon.
Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero.
Known Issues:
- AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other.
- When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar.
- The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first!
Test Plan: All the tests still pass!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
|
|
|
task
|
2015-02-21 04:24:15 +08:00
|
|
|
|
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks
Summary:
This diff does a couple things:
- Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable.
- NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request.
- Aborting a NylasAPI request now makes it call it's error callback / promise reject.
- You can now run code after perform local has completed using this syntax:
```
task = new AddRemoveTagsTask(focused, ['archive'], ['inbox'])
task.waitForPerformLocal().then ->
Actions.setFocus(collection: 'thread', item: nextFocus)
Actions.setCursorPosition(collection: 'thread', item: nextKeyboard)
Actions.queueTask(task)
```
- In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0).
- The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote".
- All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later.
- API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish.
- The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon.
Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero.
Known Issues:
- AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other.
- When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar.
- The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first!
Test Plan: All the tests still pass!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
|
|
|
makeProcessing = (task) ->
|
2015-02-21 04:24:15 +08:00
|
|
|
task.queueState.isProcessing = true
|
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks
Summary:
This diff does a couple things:
- Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable.
- NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request.
- Aborting a NylasAPI request now makes it call it's error callback / promise reject.
- You can now run code after perform local has completed using this syntax:
```
task = new AddRemoveTagsTask(focused, ['archive'], ['inbox'])
task.waitForPerformLocal().then ->
Actions.setFocus(collection: 'thread', item: nextFocus)
Actions.setCursorPosition(collection: 'thread', item: nextKeyboard)
Actions.queueTask(task)
```
- In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0).
- The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote".
- All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later.
- API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish.
- The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon.
Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero.
Known Issues:
- AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other.
- When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar.
- The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first!
Test Plan: All the tests still pass!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
|
|
|
task
|
2015-02-21 04:24:15 +08:00
|
|
|
|
2016-03-19 04:25:30 +08:00
|
|
|
makeRetryInFuture = (task) ->
|
|
|
|
|
task.queueState.retryAfter = Date.now() + 1000
|
|
|
|
|
task.queueState.retryDelay = 1000
|
|
|
|
|
task
|
|
|
|
|
|
2015-02-21 04:24:15 +08:00
|
|
|
beforeEach ->
|
2017-06-23 06:07:04 +08:00
|
|
|
spyOn(DatabaseObjectRegistry, 'isInRegistry').andReturn(true)
|
2015-02-21 04:24:15 +08:00
|
|
|
@task = new Task()
|
|
|
|
|
@unstartedTask = makeUnstartedTask(new Task())
|
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks
Summary:
This diff does a couple things:
- Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable.
- NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request.
- Aborting a NylasAPI request now makes it call it's error callback / promise reject.
- You can now run code after perform local has completed using this syntax:
```
task = new AddRemoveTagsTask(focused, ['archive'], ['inbox'])
task.waitForPerformLocal().then ->
Actions.setFocus(collection: 'thread', item: nextFocus)
Actions.setCursorPosition(collection: 'thread', item: nextKeyboard)
Actions.queueTask(task)
```
- In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0).
- The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote".
- All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later.
- API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish.
- The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon.
Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero.
Known Issues:
- AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other.
- When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar.
- The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first!
Test Plan: All the tests still pass!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
|
|
|
@processingTask = makeProcessing(new Task())
|
2016-03-19 04:25:30 +08:00
|
|
|
@retryInFutureTask = makeRetryInFuture(new Task())
|
feat(offline-mode, undo-redo): Tasks handle network errors better and retry, undo/redo based on tasks
Summary:
This diff does a couple things:
- Undo redo with a new undo/redo store that maintains it's own queue of undo/redo tasks. This queue is separate from the TaskQueue because not all tasks should be considered for undo history! Right now just the AddRemoveTagsTask is undoable.
- NylasAPI.makeRequest now returns a promise which resolves with the result or rejects with an error. For things that still need them, there's still `success` and `error` callbacks. I also added `started:(req) ->` which allows you to get the underlying request.
- Aborting a NylasAPI request now makes it call it's error callback / promise reject.
- You can now run code after perform local has completed using this syntax:
```
task = new AddRemoveTagsTask(focused, ['archive'], ['inbox'])
task.waitForPerformLocal().then ->
Actions.setFocus(collection: 'thread', item: nextFocus)
Actions.setCursorPosition(collection: 'thread', item: nextKeyboard)
Actions.queueTask(task)
```
- In specs, you can now use `advanceClock` to get through a Promise.then/catch/finally. Turns out it was using something low level and not using setTimeout(0).
- The TaskQueue uses promises better and defers a lot of the complexity around queueState for performLocal/performRemote to a task subclass called APITask. APITask implements "perform" and breaks it into "performLocal" and "performRemote".
- All tasks either resolve or reject. They're always removed from the queue, unless they resolve with Task.Status.Retry, which means they internally did a .catch (err) => Promise.resolve(Task.Status.Retry) and they want to be run again later.
- API tasks retry until they succeed or receive a NylasAPI.PermanentErrorCode (400,404,500), in which case they revert and finish.
- The AddRemoveTags Task can now take more than one thread! This is super cool because you can undo/redo a bulk action and also because we'll probably have a bulk tag modification API endpoint soon.
Getting undo / redo working revealed that the thread versioning system we built isn't working because the server was incrementing things by more than 1 at a time. Now we count the number of unresolved "optimistic" changes we've made to a given model, and only accept the server's version of it once the number of optimistic changes is back at zero.
Known Issues:
- AddRemoveTagsTasks aren't dependent on each other, so if you (undo/redo x lots) and then come back online, all the tasks try to add / remove all the tags at the same time. To fix this we can either allow the tasks to be merged together into a minimal set or make them block on each other.
- When Offline, you still get errors in the console for GET requests. Need to catch these and display an offline status bar.
- The metadata tasks haven't been updated yet to the new API. Wanted to get it reviewed first!
Test Plan: All the tests still pass!
Reviewers: evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D1694
2015-07-08 01:38:53 +08:00
|
|
|
|
|
|
|
|
afterEach ->
|
|
|
|
|
# Flush any throttled or debounced updates
|
|
|
|
|
advanceClock(1000)
|
2015-02-21 04:24:15 +08:00
|
|
|
|
2015-10-01 05:09:28 +08:00
|
|
|
describe "restoreQueue", ->
|
|
|
|
|
it "should fetch the queue from the database, reset flags and start processing", ->
|
2016-03-19 04:25:30 +08:00
|
|
|
queue = [@processingTask, @unstartedTask, @retryInFutureTask]
|
2016-02-05 06:14:24 +08:00
|
|
|
spyOn(TaskQueue, '_updateSoon')
|
2015-10-01 05:09:28 +08:00
|
|
|
|
|
|
|
|
waitsForPromise =>
|
|
|
|
|
TaskQueue._restoreQueue().then =>
|
|
|
|
|
expect(TaskQueue._queue).toEqual(queue)
|
|
|
|
|
expect(@processingTask.queueState.isProcessing).toEqual(false)
|
2016-03-19 04:25:30 +08:00
|
|
|
expect(@retryInFutureTask.queueState.retryAfter).toEqual(undefined)
|
|
|
|
|
expect(@retryInFutureTask.queueState.retryDelay).toEqual(undefined)
|
2016-02-05 06:14:24 +08:00
|
|
|
expect(TaskQueue._updateSoon).toHaveBeenCalled()
|
2015-10-01 05:09:28 +08:00
|
|
|
|
2016-05-20 02:35:38 +08:00
|
|
|
it "should remove any items in the queue which were not deserialized as tasks", ->
|
|
|
|
|
queue = [@processingTask, {type: 'bla'}, @retryInFutureTask]
|
|
|
|
|
spyOn(TaskQueue, '_updateSoon')
|
|
|
|
|
waitsForPromise =>
|
|
|
|
|
TaskQueue._restoreQueue().then =>
|
|
|
|
|
expect(TaskQueue._queue).toEqual([@processingTask, @retryInFutureTask])
|
|
|
|
|
|
2015-05-22 05:41:30 +08:00
|
|
|
describe "findTask", ->
|
|
|
|
|
beforeEach ->
|
|
|
|
|
@subclassA = new TaskSubclassA()
|
|
|
|
|
@subclassB1 = new TaskSubclassB("B1")
|
|
|
|
|
@subclassB2 = new TaskSubclassB("B2")
|
|
|
|
|
TaskQueue._queue = [@subclassA, @subclassB1, @subclassB2]
|
|
|
|
|
|
|
|
|
|
it "accepts type as a string", ->
|
|
|
|
|
expect(TaskQueue.findTask('TaskSubclassB', {bProp: 'B1'})).toEqual(@subclassB1)
|
|
|
|
|
|
|
|
|
|
it "accepts type as a class", ->
|
|
|
|
|
expect(TaskQueue.findTask(TaskSubclassB, {bProp: 'B1'})).toEqual(@subclassB1)
|
|
|
|
|
|
|
|
|
|
it "works without a set of match criteria", ->
|
|
|
|
|
expect(TaskQueue.findTask(TaskSubclassA)).toEqual(@subclassA)
|
|
|
|
|
|
|
|
|
|
it "only returns a task that matches the criteria", ->
|
|
|
|
|
expect(TaskQueue.findTask(TaskSubclassB, {bProp: 'B1'})).toEqual(@subclassB1)
|
|
|
|
|
expect(TaskQueue.findTask(TaskSubclassB, {bProp: 'B2'})).toEqual(@subclassB2)
|
2016-06-11 02:53:52 +08:00
|
|
|
expect(TaskQueue.findTask(TaskSubclassB, {bProp: 'B3'})).toEqual(undefined)
|
2015-05-22 05:41:30 +08:00
|
|
|
|
