Re: [whatwg/streams] [WritableStream] Shouldn't the state after writer.abort() be closed? (#464)

> IIRC, this was required long time ago for aborting pipeTo and having the source cancelled as if the destination is errored with the reason passed to the abort() call. It's now impossible given the writer/reader structure.

Can you explain why it is impossible now? I don't see why things would have changed. Error propagation through the pipe chain is super important; we can't lose that. The lack of it in Node streams has been very painful.

---

So I have always envisioned readable stream canceling and writable stream aborting as conceptually quite different, and not mirrors. I touched on this a little in https://github.com/whatwg/streams/blob/master/Requirements.md#you-must-be-able-to-communicate-cancel-signals-up-a-pipe-chain:

> This signal is similar to, but different than, the "close" signal described above. It implies that the data written so far is not meaningful or valid; that any queued writes should be discarded; and that a cleanup operation should be performed. For example, when a file stream represents a newly-created file, a close signal waits for all queued writes to complete, then closes the file descriptor; a new, complete file now exists on the disk. But a abort signal would throw away any queued writes and delete the file.

I think we can both agree that it's useful to have a way (currently called "abort") that throws away all written data.

I guess the question is, after throwing away all data, should your state be "errored" (with the passed error)? Or should we reserve "errored" only for when writing fails, and say that this is more of a "premature close"? (We could even have separate APIs, `.discardQueue()` and `.close()`.) I would be OK reconsidering this, but am not convinced either way yet.

---
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/464#issuecomment-223137263