Cancellable requests

[sir-boformer]

I'm using Dart Http in a Flutter app to download large files from a server.

Sometimes the user may want to cancel the request (so that the download is stopped)

The problem is that there is no way to cancel a Future in dart. Even when converted to a Stream which can be cancelled, the download will still continue running in the background.

[iqbalmineraltown]

does client.close() stop the download?

[vitor-gyant]

So, is this the proposed way to cancel a given request ? this force us to create a new client per request to allow fine-grained control to which request to cancel.

[windrunner414]

+1

[MatrixDev]

I don't think that client.close() should be considered as a proper solution. At best it can be a workaround. Problem is that Futures in Dart are not cancellable and wrapping Future in Stream cancels stream but stream can't cancel Future.

As for me this is a major language design problem but Dart team is fighting as hard as they can to not implement cancellation... There are multiple bugs with request for this and all of them are closed as Won't implement.

[intoxicated]

As for me this is a major language design problem but Dart team is fighting as hard as they can to not implement cancellation... There are multiple bugs with request for this and all of them are closed as Won't implement.

I'm wondering what are rationales not to implement cancellation? First impression on Future for me, I was like "why they wouldn't design future as cancelable", because in many cases one may want to cancel whatever future is doing. Probably there are trade-off doing so, but still. 🤔

[MatrixDev]

As for me this is a major language design problem but Dart team is fighting as hard as they can to not implement cancellation... There are multiple bugs with request for this and all of them are closed as Won't implement.

I'm wondering what are rationales not to implement cancellation? First impression on Future for me, I was like "why they wouldn't design future as cancelable", because in many cases one may want to cancel whatever future is doing. Probably there are trade-off doing so, but still. 🤔

IMHO they don't do it because of the javascript. These futures are 100% copy of promises from JS and they also can't be canceled. It might be that they are using promises under the hood when compiling for web.

As for me, I was told all my life to use resources sparingly and always close/release what I don't need. This situation with non-cancelable futures just drives me crazy...

[natebosch]

Closing as a duplicate of #424 which has more direct discussion of the API.

I'm wondering what are rationales not to implement cancellation?

Primarily because designing the API and rolling it out is very difficult in a widely used package like this. It is something we want to work on though.

First impression on Future for me, I was like "why they wouldn't design future as cancelable", because in many cases one may want to cancel whatever future is doing. Probably there are trade-off doing so, but still. 🤔

Cancellation is a potentially complex concept. Not all Future can be canceled, so putting an API there could end up causing confusion. The idiomatic solution for cancelable operations is CancelableOperation from package:async.

Changing returns types from Future to CancelableOperation is one of the designs we have considered, but it isn't currently a direction we are planning on pushing towards.

IMHO they don't do it because of the javascript. These futures are 100% copy of promises from JS and they also can't be canceled. It might be that they are using promises under the hood when compiling for web.

Dart Future predates JS Promise. Futures are not a copy of promise, I don't know whether they had any influence on the design of promises. The first commit to https://github.com/then/promise was at the very end of 2012, and Dart had Future in the core libraries since 2011.

We don't use Promise currently when compiling to JS, although that is something that we may look at after dropping support for browser that don't provide it.