Re: [whatwg/streams] Define WritableStreamDefaultController.signal (#1132)

@domenic commented on this pull request.



> @@ -4421,7 +4441,8 @@ the {{WritableStream}}'s public API.
  1. [=Reject=] |stream|.[=WritableStream/[[inFlightCloseRequest]]=] with |error|.
  1. Set |stream|.[=WritableStream/[[inFlightCloseRequest]]=] to undefined.
  1. Assert: |stream|.[=WritableStream/[[state]]=] is "`writable`" or "`erroring`".
- 1. If |stream|.[=WritableStream/[[pendingAbortRequest]]=] is not undefined,
+ 1. If |stream|.[=WritableStream/[[pendingAbortRequest]]=] is not undefined and |error| is not an

I think I need a non-artificial example. Why did you reject the closed promise in the first place? I would think that the signal would have no impact on the promise returned from close, but instead would be used while opening a file or writing to it.

E.g.

```js
let fd;
const ws = new WritableStream({
  start(c) {
    fd = await fs.open(filePath, { signal: c.signal });
  },
  write(chunk, c) {
    await fd.write(chunk, { signal: c.signal });
  }
  close() {
    await fd.close(); // no signal; closing isn't abortable
  }
});
```

If you changed the line to `await fd.close({ signal: c.signal })`, i.e. you let someone abort in the middle of closing---then yes, I'd expect `ws.closed` to reject with an "AbortError" DOMException, because we failed to close the stream due to the closing process being aborted!

-- 
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/pull/1132#discussion_r645865603