us.abort() is not called if us.write() fails

[ricea]

Currently an exception or rejection from us.write() will not result in us.abort() being called. If the underlying sink wants to free resources, it has to do it before returning the error. Something like this:

class UnderlyingSink {
  start() { this.handle = AcquireHandleSomehow(); }
  write(chunk) {
    return this.handle.write(chunk).catch(e -> {
      return this.close().then(() => throw e);
    });
  }
  close() {
    return this.handle.freeResources();
  }
}

If us.abort() (with fallback to us.close()) was called automatically, then this would become a lot simpler.

[ricea]

I think we should also resolve the same question for controller.error() in this issue, as it is closely related. Currently controller.error() does not result in a call to us.abort().

[domenic]

I realized that there is a somewhat analogous situation for readable streams actually :-/. E.g. in https://streams.spec.whatwg.org/#example-rs-pull, if fs.read rejects, we do not call fs.close. Or if we call rsController.error(e). I am not sure what to think about that.

[ricea]

My severity analysis:

Naively written sources and sinks will tend to leak resources. Some number of hours will be lost to debugging these resource leaks. Garbage collection will mitigate this issue for some Javascript-authored streams, but not all. For example, a WebSocket will stay alive as long as it is open and a message handler exists, so GC would not clean them up.

My usability analysis:

If finally() existed, it would be unambiguous what to do here. On the other hand, abort() or close() being called when there wasn't a corresponding abort() or close() at the reader/writer level might be considered confusing.

My proposal:

Do nothing now. Discuss adding finally() to sources and sinks as a "v2" feature.

[domenic]

The proposal sounds good. However I wonder if we should also remove the fallback from abort to close, to maintain the idea that the "v1" feature set is focused around obvious mappings, and not around convenient cleanup---especially convenient cleanup that only works in one of the many cases.

Also we should fix up all the examples to do proper cleanup.

[tyoshino]

+1 for removal of the fallback

[ricea]

+1 for removal of the fallback