streams
streams copied to clipboard
whatwg
add TrasformStream finally callback
Closes https://github.com/whatwg/streams/issues/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: https://github.com/denoland/deno/pull/14686
- Node.js: …
(See WHATWG Working Mode: Changes for more details.)
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...
sure, seems i somehow missed that in the original issue, will change this PR to that
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.
one issue i currently havent handled yet is what to do in case the
finallycallback is a promise. The call in the flushPromise fulfilled case should be easier, however the other call intransformStreamErrorWritableAndUnblockWrite, 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?
Opened a new PR at https://github.com/whatwg/streams/pull/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.
