-
Notifications
You must be signed in to change notification settings - Fork 5k
[QUIC] Add QuicStream.WaitForWriteCompletionAsync #58236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[QUIC] Add QuicStream.WaitForWriteCompletionAsync #58236
Conversation
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
Tagging subscribers to this area: @dotnet/ncl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some small questions, otherwise looks good!
Thanks!
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/Mock/MockStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/Mock/MockStream.cs
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/Mock/MockConnection.cs
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Show resolved
Hide resolved
Just an FYI that I'm also looking at this, will post my review today |
src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicStream.cs
Outdated
Show resolved
Hide resolved
@@ -1040,6 +1145,12 @@ private static uint HandleEventShutdownComplete(State state, ref StreamEvent evt | |||
|
|||
shouldReadComplete = CleanupReadStateAndCheckPending(state, ReadState.ReadsCompleted); | |||
|
|||
if (state.ShutdownWriteState == ShutdownWriteState.None) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure this state is expected here? As you've mentioned in comment for HandleEventSendShutdownComplete, by the time we receive SHUTDOWN_COMPLETE event, we should either completed ShutdownWriteState already, or it is a connection close, which is handled separately in HandleEventConnectionClose. I think we may leave the logic here, but guard it with Debug.Assert... what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even as a fallback, I think it is especially strange to complete it successfully here... IMO successful completion should only happen in HandleEventSendShutdownComplete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is one situation where you can get to this point without HandleEventSendShutdownComplete
: if the stream is unidirectional and there are no writes.
Perhaps WaitForWriteCompleteAsync
should error if it is called for this type of stream. I'm going to add that as a TODO comment. I'll also explain it in the logic inside HandleEventShutdownComplete
. The exact behavior can be figured out in .NET 7.
Assert.Equal(1, received); | ||
Assert.True(serverStream.ReadsCompleted); | ||
|
||
long sendAbortErrorCode = await waitForAbortTcs.Task; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could that be just
var ex = await Assert.ThrowsAsync<QuicStreamAbortedException>(() => serverStream.WaitForWriteCompletionAsync());
Assert.Equal(ExpectedErrorCode, ex.ErrorCode);
? (Here and below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to test the wait part of WaitForWriteCompletionAsync
[Fact] | ||
public async Task WaitForWriteCompletionAsync_ClientReadAborted_Throws() | ||
{ | ||
const int ExpectedErrorCode = 0xfffffff; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to comment that we use the same constant as a default error code on Dispose, but we actually use 0xffffffff
, not 0xfffffff
😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to choose a different number, diff between 7x f
and 8x f
is too small to be noticeable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assert.Equal will show decimal representation, so it will be easier to distinguish... but it will be harder to catch in the future if some other test will accidentally use 8xf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied the value from a different test. IMO lets leave it as is for now, and if you want to change all instances of this value then it can be done in a future PR.
I see that new tests are failing for Mock. Aborts didn't work properly on Mocks before, and I guess the changes didn't fix them fully... 😢 I wonder if we really want to invest into fixing Mock at this point. I would vote for no. Thoughts? @ManickaP @geoffkizer |
We can disable the tests for mocks specifically, we have a precedent for that. So unless it's super obvious and easy to fix, I wouldn't put much effort in it. |
+1 to this Once 6.0 is done we should discuss whether to keep Mock at all. But for now let's just disable specific test and not make any major changes. |
It was super obvious and easy to fix. |
All PR feedback has been applied. I'm creating a release/6.0 (RC2) backport issue with details about the change for @adityamandaleeka to take to tactics tomorrow. Hopefully there are no more changes. If there is something then I can apply it to both PRs. |
7fdedf2
to
75be833
Compare
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1184544908 |
Unrelated test failure (likely) #734 - see log
runtime-staging failures seem to be unrelated, rerunning. |
/backport to release/6.0 |
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1185710989 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
dotnet-linker-tests failure - hit 120min timeout. Rerunning. |
Thanks everyone! |
Fixes #58229