Re: [whatwg/streams] Refactor writable stream erroring to be centralized (#705)

domenic commented on this pull request.



>    const abortRequest = stream._pendingAbortRequest;
   stream._pendingAbortRequest = undefined;
   const promise = WritableStreamDefaultControllerAbort(stream._writableStreamController, abortRequest._reason);
   promise.then(
     abortRequest._resolve,
     abortRequest._reject
   );
+  stream._backpressure = false;

OK, I think I understand what's going on.

If there is a _pendingAbortRequest, WritableStreamError uses that as a signal to not mess with _readyPromise: it's already been rejected by the initial WritableStreamAbort() that set the pending abort request.

In the case we're worried about, WritableStreamHandleAbortRequestIfPending (which calls WritableStreamFinishAbort which calls WritableStreamError), we also don't want to mess with the ready promise, for the same reason---we were previously aborted, and that already rejected the ready promise. However, since WritableStreamHandleAbortRequestIfPending needs to manage the abort request itself, it clears out _pendingAbortRequest. So by the time WritableStreamError is reached, it thinks there is no _pendingAbortRequest, and goes to mess with the _readyPromise.

One reaction to this might be that attempting to use this _pendingAbortRequest signal to manage _readyPromise is not sound and we should use something _readyPromise-specific. That seems a little drastic though so I am not sure.

-- 
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/705#discussion_r107872344