`QuicStream.ReadsClosed` completes before EOS is consumed

[bentoi]

This is related to the discussion on #77216 .

It looks like today QuicStream.ReadsClosed gets completed as soon as the last piece of data is returned by QuicStream.ReadAsync and before QuicStream.ReadAsync returns 0 to indicate the end of the stream.

This is demonstrated by the test case attached. What are the excepted semantics for ReadsClosed?

Should it complete:

1. as soon as EOS is received and even if there's buffered data
2. when EOS is received and after the buffered data is consumed
3. when EOS is received and after the buffered data and EOS are consumed.

quicstreameos.zip

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This is related to the discussion on #77216 .

It looks like today QuicStream.ReadsClosed gets completed as soon as the last piece of data is returned by QuicStream.ReadAsync and before QuicStream.ReadAsync returns 0 to indicate the end of the stream.

This is demonstrated by the test case attached. What are the excepted semantics for ReadsClosed?

Should it complete:

1. as soon as EOS is received and even if there's buffered data
2. when EOS is received and after the buffered data is consumed
3. when EOS is received and after the buffered data and EOS are consumed.

quicstreameos.zip

Author:	bentoi
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This is related to the discussion on #77216 .

It looks like today QuicStream.ReadsClosed gets completed as soon as the last piece of data is returned by QuicStream.ReadAsync and before QuicStream.ReadAsync returns 0 to indicate the end of the stream.

This is demonstrated by the test case attached. What are the excepted semantics for ReadsClosed?

Should it complete:

1. as soon as EOS is received and even if there's buffered data
2. when EOS is received and after the buffered data is consumed
3. when EOS is received and after the buffered data and EOS are consumed.

quicstreameos.zip

Author:	bentoi
Assignees:	-
Labels:	untriaged, area-System.Net.Quic
Milestone:	-

[ManickaP]

2. when EOS is received and after the buffered data is consumed

is the answer here.

It shouldn't be case 3. as the goal is to get the info about reading side state without issuing ReadAsync. And for case 1., it would be confusing to report reading side closed while still having data in buffer. Note that the peer might close the writing side separately from the last data. Also the task gets finished not only with FIN flag, but also with AbortRead (send STOP_SENDING) or the peers RESET_STREAM as a corresponding exception.

If you have different opinions on the behavior, please do share them. We can discuss them and re-evaluate the current behavior.

Final note, I looked at your example and since you're using await using var localStream ... and await using var remoteStream ... you don't need DisposeWhenClosed, await using will take care of that. And I'm not sure that hooking up DisposeAsync as a follow up on Reads/WritesClosed is the best way to do this. They weren't designed with something like this in mind, but I do concur that this might be valid use-case and we could make it behave somewhat better at least.

[ManickaP]

Triage: marking as a question/discussion for now. There might not be anything actionable from this and if so, it should be fixed in 8.0.