-
Notifications
You must be signed in to change notification settings - Fork 576
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cancellation trumps error in -[BFTask taskForCompletionOfAllTasks:] #87
Comments
@nlutsenko-fb @grantland
Is this the desired behaviour for |
This seems like a bug in the iOS implementation. The .NET docs state that it goes Error > Cancelled > Success (https://msdn.microsoft.com/en-us/library/hh194766(v=vs.110).aspx) and our Android implementation follows this as well: Task<Void> taskA = Task.forError(new RuntimeException("This task failed."));
Task<Void> taskB = Task.forResult(null);
Task<Void> taskC = Task.cancelled();
Task.whenAll(Arrays.asList(taskA, taskB, taskC)).continueWithTask(new Continuation<Void, Task<Void>>() {
@Override
public Task<Void> then(Task<Void> task) throws Exception {
Log.d("test", "isFaulted=" + task.isFaulted() + " isCancelled=" + task.isCancelled() + " isComplete=" + task.isCompleted());
return null;
}
}).waitForCompletion();
|
Fixed by #93 |
Thanks guys! |
I have a scenario where I have many, many network requests to make. I would like to provide a BFTask for the completion of all of them.
I want to be able to cancel them if necessary. Also, if any of them individually fail, I would like to abort the ones not yet dispatched. They are all scheduled on a BFExecutor built from an NSOperationQueue.
Each task begins with a check on a shared cancellationToken to see if they should proceed. If the request fails, it returns its error and sets the cancellationToken to true. The remaining tasks in the queue then check the cancellationToken and dutifully return -[BFTask cancelledTask] when they get their turn.
The problem is that the continuation block for -[BFTask taskForCompletionOfAllTasks:] gives cancellations precedent over errors. So, the task for the completion of all of them returns a cancelled task instead of an error. There's an important distinction there. I want to message errors in my user experience, but not cancellations.
I suspect it's intentional, but I don't know why. Is my use of the same cancellation token for canceling and errors discouraged? Or is this something that you could possibly change (to give errors precent over cancellations)?
The text was updated successfully, but these errors were encountered: