Re: [whatwg/streams] Aborting a writable stream should not abort writes in progress (#611)

The example I have been thinking about is an application which reads a resource from the network, checks it for validity, and appends it to a file. If the resource is invalid, it aborts, truncates the file to where it was to start with, and retries. It looks like this:

```javascript
fetch(resource)
  .then(response -> response.body)
  .pipeThrough(new TransformStream(validator))
  .pipeTo(fileStream)
  .catch(truncateFileAndRetry);
```

The problem here is that if the pipeTo() promise rejects before writes by the underlying sink of `fileStream` have finished, then those writes will race with the file truncation.

Without these changes, the underlying sink can ensure deterministic behaviour by preventing abort() from fulfilling until any underlying operations are complete. However, this requirement is non-obvious and requires extra book-keeping inside the sink implementation.

With the changes to write(), the implementer of the underlying sink would have to go out of their way to get this wrong.

The reverse issue is when the user of the WritableStream is just discarding the sink and just wants abort() to be instant. Since they can easily implement this themselves by calling abort() and setting some flag to disregard any promises that settle after that point, I don't see this as a significant problem.

Unfortunately, this doesn't throw light on the close() vs. abort() issue because pipeTo() won't abort() once close() has started. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/611#issuecomment-261919328