Skip to content
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 can't be controlled finely enough #663

Closed
fresheneesz opened this issue Jun 17, 2015 · 1 comment
Closed

Cancellation can't be controlled finely enough #663

fresheneesz opened this issue Jun 17, 2015 · 1 comment

Comments

@fresheneesz
Copy link
Contributor

If you have multiple levels of cancellable processes in the different promise chains, currently bluebird has no way of specifying what you want to cancel - either the whole thing will be canceled, or none of it.

Conceptual example:

promise x

Process A {
  step 1: Wait on x
  step 2: 
  step 3: 
}
Process B { 
  step 1: Wait on x
  step 2: 
  step 3: 
}

In this example, if you want to cancel process A before promise x has resolved, process B will never complete, even tho it doesn't have anything to do with process A's cancellation.

A concrete example:

var p = Promise.resolve('mooose').delay(1000).cancellable()

p.then(function(x) {
    console.log("Process A done")
}).catch(function(e) {
    console.log("Process A was canceled (or cancelled)! Hopefully because p was cancelled directly?")
})

var processB = p.then(function(x) {
    console.log("Process B started")
})

var x = processB.cancellable().then(function() {
    console.log("Process B done")
}).catch(function(e) {
    console.log("Process B was canceled (or cancelled)!")
})

processB.cancel()
// x.cancel()          // same result

The result of this is that both process A and process B are cancelled when I only wanted to cancel process B. Is there something i'm missing about this API that resolves this?

What I would expect is that instead of cancel cancelling the farthest ancestor promise, that it would propogate to the closest descendant promise that hasn't been resolved. That way I could call processB.cancel() and only expect to see the CancellationException in one place here. Better yet would be to be able to define the boundaries of a cancelable process in some way. For example, with an api like x.cancel(processB) which would mean that the cancellation propogates up to the farthest anscestor promise of x up to processB (at which point it stops and triggers a rejection on that promise). That way cancellable processes can be nested inside other cancellable processes - exactly what you want in a complicated application.

Thoughts?

@fresheneesz
Copy link
Contributor Author

Closing because there's already much discussion at cancellation overhaul. Also, I've come up with a better proposal i wrote there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant