QuicStream.WritesClosed continuation ran before the Quic reset frame is sent?

[bentoi]

Kind of related to #79818 but for QuicStream.WritesClosed this time.

When aborting a stream writing side, it looks like the WritesClosed continuation is ran before the reset frame is actually sent to the peer. If the continuation disposes of the stream, the peer ReadAsync sometime completes successfully.

It's also actually not clear to me why DisposeAsync doesn't abort the stream with the default error code.

I've attached a test case. Here's the test case failure:

Running test...
Running test...
Running test...
Running test...
Running test...
Unhandled exception. System.InvalidOperationException: didn't expect ReadAsync to succeed with 0 bytes!
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 60
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 64
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 64
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 43
   at Program.<Main>(String[] args)

quicabortwrite.zip

[ghost]

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

Issue Details

---

Kind of related to #79818 but for QuicStream.WritesClosed this time.

When aborting a stream writing side, it looks like the WritesClosed continuation is ran before the reset frame is actually sent to the peer. If the continuation disposes of the stream, the peer ReadAsync sometime completes successfully.

It's also actually not clear to me why DisposeAsync doesn't abort the stream with the default error code.

I've attached a test case. Here's the test case failure:

Running test...
Running test...
Running test...
Running test...
Running test...
Unhandled exception. System.InvalidOperationException: didn't expect ReadAsync to succeed with 0 bytes!
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 60
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 64
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 64
   at Program.Main(String[] args) in /home/vagrant/workspace/quicabortwrite/Program.cs:line 43
   at Program.<Main>(String[] args)

quicabortwrite.zip

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

[ManickaP]

Yes, the order of setting the Task is before aborting on the wire. What should not happen is that DisposeAsync in this case closes gracefully the writing side, we should fix that.
As for why DisposeAsync closes gracefully the writing side in the default case. It's for when QuicStream is used as Stream, the base class, which knows nothing about CompleteWrites. We want to keep the "happy-path" of using (stream) { read; write; } to behave the same as other types of stream, i.e. to close gracefully.

Triage: we should fix the DisposeAsync behavior in 8.0. We might discuss more the timing of when the Writes/ReadsClosed tasks are finished in regards to the other operations.