Skip to content

Timing differences on start promise on WritableStream #1298

Open
@saschanaz

Description

@saschanaz

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:

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 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions