Lock a closed or errored native stream on tee() - #7504
Conversation
|
LGTM |
guybedford
left a comment
There was a problem hiding this comment.
LGTM. Verified locally: the suite passes on both cells, and teeClosedNativeBodyLocksOriginal fails on the TS cell with the acquireReadableStreamDefaultReader line removed, so it's a real pin. Also probed the errored half (a SELF body that controller.error()s mid-stream, read to error, reader released, then tee()): both TS and C++ leave the original locked, a second tee() throws, and both branch reads reject. The internal reader on an errored stream is fine since initializeReadableStreamGenericReader marks the rejected closed promise handled before rejecting it.
Optional: the commit title covers closed and errored, but the test only pins the closed case. An /erroring SELF endpoint alongside /delayed in main.js would let the test loop over a third body and cover the errored path too.
tee() of a closed or errored native-backed stream returned two branches in the same state but left the original unlocked, so it could be teed again. The comment claimed this mirrored the queued path, which locks. It now acquires the internal reader as the other tee paths do. Parity with C++, whose tee() locks the original in every state. Behind the experimental typescript_implemented_streams flag.
39cb489 to
b705473
Compare
tee() of a closed or errored native-backed stream returned two branches
in the same state but left the original unlocked, so it could be teed
again. The comment claimed this mirrored the queued path, which locks.
It now acquires the internal reader as the other tee paths do.