Need to define the current Realm for pipeTo operations

[bzbarsky]

https://streams.spec.whatwg.org/#rs-pipe-to defines things like calling ReadableStreamReaderGenericRelease during shutdown. ReadableStreamReaderGenericRelease step 4 needs to create a "promise rejected with", which means it needs to know what global to use for that.

Presumably the global is that of the current Realm. But it's not clear to me that the current Realm is well-defined on all the paths that can lead to shutdown in the parallel section of pipeTo. In particular, nothing really indicates that if dest.[[state]] is or becomes "errored" has to happen while there is a current Realm set up.

It would be good to make this clearer, ideally by explicitly saying what Realm should be used here or having a note explaining how the existence of a current Realm is guaranteed.

We should probably also have tests for this, if we don't already.

[domenic]

Sorry for the delay here. I think the intent is that we should be queuing a task back to the main thread once we get into any of shutdown with an action or shutdownEDIT: upon further consideration, finalize is the right place for this, as that's the part that starts being observable to user code. So, we should definitely add "queue a task" in there.

Of course, just queuing a task doesn't really help re-establish the current realm. This is reminiscent of our discussions in whatwg/webidl#135, and gives me a new appreciation for @jyasskin's proposal. If we were to do what I was suggesting, and require being explicit, we'd have to pass a realm from pipeTo to ReadableStreamReaderGenericRelease to "a promise resolved with". That is not fun.

On the other hand, I don't think this promise is observable. The reader in question is never exposed to author code, and so you can't observe its [[closedPromise]]. As such, I can't imagine a way to write tests for this. So maybe the right fix for this particular case is to make that clearer.

[bzbarsky]

On the other hand, I don't think this promise is observable.

Hmm. Claims like that in JS need proof, and the proof is liable to become invalid as TC-39 makes changes....

But yes, if we can make it clear that this thing is not observable that would solve this particular problem.