Mailspring/internal_packages/worker-ui/lib/developer-bar.cjsx
Evan Morikawa 092c28d2c0 fix(tasks): don't continue if dependent task fails
Summary:
Fixes T4291

If I made a final edit to a pre-existing draft and sent, we'd queue a
`SyncbackDraftTask` before a `SendDraftTask`. This is important because
since we have a valid draft `server_id`, the `SendDraftTask` will send by
server_id, not by POSTing the whole body.

If the `SyncbackDraftTask` fails, then we had a very serious issue whereby
the `SendDraftTask` would keep on sending. Unfortunately the server never
got the latest changes and sent the wrong version of the draft. This
incorrect version would show up later when the `/send` endpoint returned
the message that got actually sent.

The solution was to make any queued `SendDraftTask` fail if a dependent
`SyncbackDraftTask` failed.

This meant we needed to make the requirements for `shouldWaitForTask`
stricter, and block if tasks failed.

Unfortunatley there was no infrastructure in place to do this.

The first change was to change `shouldWaitForTask` to `isDependentTask`.
If we're going to fail when a dependent task fails, I wanted the method
name to reflect this.

Now, if a dependent task fails, we recursively check the dependency tree
(and check for cycles) and `dequeue` anything that needed that to succeed.

I chose `dequeue` as the default action because it seemed as though all
current uses of `shouldWaitForTask` really should bail if their
dependencies fail. It's possible you don't want your task dequeued in this
dependency case. You can return the special `Task.DO_NOT_DEQUEUE_ME`
constant from the `onDependentTaskError` method.

When a task gets dequeued because of the reason above, the
`onDependentTaskError` callback gets fired. This gives tasks like the
`SendDraftTask` a chance to notify the user that it bailed. Not all tasks
need to notify.

The next big issue was a better way to determine if a task truely errored
to the point that we need to dequeue dependencies. In the Developer Status
area we were showing tasks that had errored as "Green" because we caught
the error and resolved with `Task.Status.Finished`. This used to be fine
since nothing life-or-death cared if a task errored or not. Now that it
might cause abortions down the line, we needed a more robust method then
this.

For one I changed `Task.Status.Finished` to a variety of finish types
including `Task.Status.Success`. The way you "error" out is to `throw` or
`Promise.reject` an `Error` object from the `performRemote` method. This
allows us to propagate API errors up, and acts as a safety net that can
catch any malformed code or unexpected responses.

The developer bar now shows a much richer set of statuses instead of a
binary one, which was REALLY helpful in debugging this. We also record
when a Task got dequeued because of the conditions introduced here.

Once all this was working we still had an issue of sending old drafts.

If after a `SyncbackDraftTask` failed, now we'd block the send and notify
the users as such. However, if we tried to send again, there was a
separate issue whereby we wouldn't queue another `SyncbackDraftTask` to
update the server with the latest information. Since our changes were
persisted to the DB, we thought we had no changes, and therefore didn't
need to queue a `SyncbackDraftTask`.

The fix to this is to always force the creation of a `SyncbackDraftTask`
before send regardless of the state of the `DraftStoreProxy`.

Test Plan: new tests. Lots of manual testing

Reviewers: bengotow

Reviewed By: bengotow

Subscribers: mg

Maniphest Tasks: T4291

Differential Revision: https://phab.nylas.com/D2156
2015-10-21 10:33:43 -07:00

141 lines
4.7 KiB
CoffeeScript

_ = require 'underscore'
React = require 'react/addons'
{DatabaseStore,
AccountStore,
TaskQueue,
Actions,
Contact,
Message} = require 'nylas-exports'
DeveloperBarStore = require './developer-bar-store'
DeveloperBarTask = require './developer-bar-task'
DeveloperBarCurlItem = require './developer-bar-curl-item'
DeveloperBarLongPollItem = require './developer-bar-long-poll-item'
class DeveloperBar extends React.Component
@displayName: "DeveloperBar"
@containerRequired: false
constructor: (@props) ->
@state = _.extend @_getStateFromStores(),
section: 'curl'
filter: ''
componentDidMount: =>
@taskQueueUnsubscribe = TaskQueue.listen @_onChange
@activityStoreUnsubscribe = DeveloperBarStore.listen @_onChange
componentWillUnmount: =>
@taskQueueUnsubscribe() if @taskQueueUnsubscribe
@activityStoreUnsubscribe() if @activityStoreUnsubscribe
render: =>
<div className="developer-bar">
<div className="controls">
<div className="btn-container pull-left">
<div className="btn" onClick={ => @_onExpandSection('queue')}>
<span>Queue Length: {@state.queue?.length}</span>
</div>
</div>
<div className="btn-container pull-left">
<div className="btn" onClick={ => @_onExpandSection('long-polling')}>
{ _.map @state.longPollState, (val, key) =>
<div title={"Account ID #{key} - State: #{val}"} key={key} className={"activity-status-bubble state-" + val}></div>
}
<span>Long Polling</span>
</div>
</div>
<div className="btn-container pull-left">
<div className="btn" onClick={ => @_onExpandSection('curl')}>
<span>Requests: {@state.curlHistory.length}</span>
</div>
</div>
<div className="btn-container pull-right">
<div className="btn" onClick={ => Actions.sendFeedback() }>Feedback</div>
</div>
</div>
{@_sectionContent()}
<div className="footer">
<div className="btn" onClick={@_onClear}>Clear</div>
<input className="filter" placeholder="Filter..." value={@state.filter} onChange={@_onFilter} />
</div>
</div>
_sectionContent: =>
expandedDiv = <div></div>
matchingFilter = (item) =>
return true if @state.filter is ''
return JSON.stringify(item).indexOf(@state.filter) >= 0
if @state.section == 'curl'
itemDivs = @state.curlHistory.filter(matchingFilter).map (item) ->
<DeveloperBarCurlItem item={item} key={item.id}/>
expandedDiv = <div className="expanded-section curl-history">{itemDivs}</div>
else if @state.section == 'long-polling'
itemDivs = @state.longPollHistory.filter(matchingFilter).map (item) ->
<DeveloperBarLongPollItem item={item} key={"#{item.cursor}-#{item.timestamp}"}/>
expandedDiv = <div className="expanded-section long-polling">{itemDivs}</div>
else if @state.section == 'queue'
queue = @state.queue.filter(matchingFilter)
queueDivs = for i in [@state.queue.length - 1..0] by -1
task = @state.queue[i]
# We need to pass the task separately because we want to update
# when just that variable changes. Otherwise, since the `task`
# pointer doesn't change, the `DeveloperBarTask` doesn't know to
# update.
status = @state.queue[i].queueState.status
<DeveloperBarTask task={task}
key={task.id}
status={status}
type="queued" />
queueCompleted = @state.completed.filter(matchingFilter)
queueCompletedDivs = for i in [@state.completed.length - 1..0] by -1
task = @state.completed[i]
<DeveloperBarTask task={task}
key={task.id}
type="completed" />
expandedDiv =
<div className="expanded-section queue">
<div className="btn queue-buttons"
onClick={@_onDequeueAll}>Remove Queued Tasks</div>
<div className="section-content">
{queueDivs}
<hr />
{queueCompletedDivs}
</div>
</div>
expandedDiv
_onChange: =>
@setState(@_getStateFromStores())
_onClear: =>
Actions.clearDeveloperConsole()
_onFilter: (ev) =>
@setState(filter: ev.target.value)
_onDequeueAll: =>
Actions.dequeueAllTasks()
_onExpandSection: (section) =>
@setState(@_getStateFromStores())
@setState(section: section)
_getStateFromStores: =>
queue: TaskQueue._queue
completed: TaskQueue._completed
curlHistory: DeveloperBarStore.curlHistory()
longPollHistory: DeveloperBarStore.longPollHistory()
longPollState: DeveloperBarStore.longPollState()
module.exports = DeveloperBar