add TrasformStream finally callback

[crowlKats]

Closes #1212

The only thing left is what to do in case of the callback throwing/rejecting (and potentially somehow awaiting the callback? unsure if thats necessary).

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …
  • Deno: feat(ext/web/streams): TransformStream cancel denoland/deno#14686
  • Node.js: …

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[domenic]

I thought the plan was to add finally() handlers to all streams?

Adding a cancel() handler doesn't make a lot of sense to me since you can't cancel a transform stream...

[crowlKats]

sure, seems i somehow missed that in the original issue, will change this PR to that

[crowlKats]

@domenic adjusted the behaviour & name

[crowlKats]

one issue i currently havent handled yet is what to do in case the finally callback is a promise. The call in the flushPromise fulfilled case should be easier, however the other call in transformStreamErrorWritableAndUnblockWrite, unsure how to proceed.

[MattiasBuelens]

This algorithm will already have been cleared by TransformStreamDefaultControllerClearAlgorithms in step 1, so this won't work.

[crowlKats]

yea, it currently isnt, as i am unsure how to proceed without moving the clear algs

[MattiasBuelens]

Once again, this algorithm has already been cleared in step 4.

[andreubotella]

one issue i currently havent handled yet is what to do in case the finally callback is a promise. The call in the flushPromise fulfilled case should be easier, however the other call in transformStreamErrorWritableAndUnblockWrite, unsure how to proceed.

Handling this is complicated, since TransformStreamErrorWritableAndUnblockWrite is making it so writing to the writable stream will throw, and this cannot be delayed until the finally promise resolves. So the finally callback can't work in a similar way to Promise.prototype.finally.

Should we ignore the returned promise and let it cause an unhandled promise rejection?

[lucacasonato]

Opened a new PR at #1283 that specs this with an alternative approach and fixes the "use after free" issues. That PR also has tests and an the reference implementation has been updated.

[crowlKats]

Closing as Luca implemented this.