Again, when working on webtransport support, my test uncovered after rebasing after 3 weeks absence,
an issue that data can be lost. (was not there before, can be changes in quic or stream iter).
What the test does is, create a server side unidirectional stream with some bytes and immediately closing the stream.
The client is unable to read the data, because I use:
this.readiterator_ = this.stream[Symbol.asyncIterator]()
and then later call:
await this.readiterator_.next()
when the code needs it.
The problem is, that only at the call to next() the async iterator of QuicStream is called, that creates the reader on the C++ Stream object.
However, the #handle is destroyed once the stream is closed (from the server side) and a later call to this.readiterator_.next() can not retrieve that data on client side as the #handle is gone, and the data was in its accumulation buffer.
I can work around this problem, by calling next() early and awaiting the promise later. (at least I hope)
But I am wondering, if the lazy allocation of the stream's reader is a good idea. I know from user querys about my webtransport package, that a lot of user use streams to send messages and immediately close them (though I do not like this pattern), but this use pattern may result into the same problem.
@pimterry @jasnell
What do you think about this?
Again, when working on webtransport support, my test uncovered after rebasing after 3 weeks absence,
an issue that data can be lost. (was not there before, can be changes in quic or stream iter).
What the test does is, create a server side unidirectional stream with some bytes and immediately closing the stream.
The client is unable to read the data, because I use:
and then later call:
when the code needs it.
The problem is, that only at the call to
next()the async iterator ofQuicStreamis called, that creates the reader on the C++ Stream object.However, the
#handleis destroyed once the stream is closed (from the server side) and a later call tothis.readiterator_.next()can not retrieve that data on client side as the#handleis gone, and the data was in its accumulation buffer.I can work around this problem, by calling
next()early and awaiting the promise later. (at least I hope)But I am wondering, if the lazy allocation of the stream's reader is a good idea. I know from user querys about my webtransport package, that a lot of user use streams to send messages and immediately close them (though I do not like this pattern), but this use pattern may result into the same problem.
@pimterry @jasnell
What do you think about this?