[whatwg/streams] Timing differences on start promise on WritableStream (Issue #1298)

### What is the issue with the Streams Standard?

I was investigating further on #1296 and found that this snippet emits different logs on different implementations:

```js
new WritableStream({
  async start() {},
  async write(chunk) {
    console.log(chunk)
  }
}).getWriter().write('write');
Promise.resolve('promise').then(console.log)
```

* The reference impl, Gecko, Deno: promise write
* WebKit, Blink, Node.js: write promise

[UnderlyingSinkStartCallback](https://streams.spec.whatwg.org/#callbackdef-underlyingsinkstartcallback) returns `any`, so the IDL promise conversion doesn't happen here, and thus `startResult` of step 15 becomes the raw JS promise. Then step 16 wraps it with a new promise via "a promise resolved with" algorithm, and thus it takes two rounds for the listener of `startPromise` to be called. `Promise.resolve().then()` only takes one round, so the result here should be `promise write`, as the reference impl shows.

Instead, WebKit and Blink somehow effectively uses `Promise.resolve()` on the return value of startPromise: https://bugzilla.mozilla.org/show_bug.cgi?id=1859853#c1

I think we need a discussion as the implementations are divided here. I guess the spec ended up with "a promise resolved with" wrapper steps as that's what Web IDL does, but is there a real point to wrap `startResult` that way? What bad thing happens when we just use `Promise.resolve()` as WebKit/Blink/Node.js do?

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

Message ID: <whatwg/streams/issues/1298@github.com>