Cancel method

[lbud]

It would be cool to have a cancel method. Right now I'm using this to pipe an s3scan.Scan to another transform stream, and then when I've gotten as much as I need I end that stream, but trying to end the scan stream results in a write after end error because of the queue. Something like a purge or cancel option to delete all queued items and cancel the stream would be useful in cases like this.

[rclark]

@lbud this is something that I've never quite figured out how to do right, but agree that it would be helpful. Have any good ideas? O_o

[lbud]

@rclark I'm not positive if this would f with the stream order-of-operations, but I was looking at d3/d3-queue#21 (comment) yesterday — could we do something like that? And listen for a specific cancel error type and treat it not as an error?

[rclark]

Once you've deferred work, there's nothing that you can do to stop it really. In the get stream case, there may be up to 1000 requests outstanding when you want to .cancel().

• You can use a semaphore that tells the stream to stop .pushing more data after you .cancel() -- just set stream.canceled = true and make sure to check that it's falsy before every .push().
• You could decrease the max number of outstanding requests so that you've got less waiting to do once you .cancel()
• To me the curious part of your question is finding the right state to put the transform stream in when you .cancel()? Should you .end()? What does that mean considering there's a key-listing stream that may still have an open .pipe? Should you .unpipe()? Should you emit an error?