-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[HTTP/3] Test bug (flaky) - premature connection close - need some synchro on app level #55508
Comments
Tagging subscribers to this area: @dotnet/ncl Issue DetailsI've seen it (rarely) happening on
Callstack shows This brings me to thing we've discussed today:
This exact issue manifests itself in our HTTP/3 tests, so we need to add some kind of app-level synchro there (or think of another solution).
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsI've seen it (rarely) happening on
Callstack shows This brings me to thing we've discussed today:
This exact issue manifests itself in our HTTP/3 tests, so we need to add some kind of app-level synchro there (or think of another solution).
|
Failures 5/20-7/20 (incl. PRs):
|
I suspect this is related to #55025 The loopback server doesn't ever close the connection today. But it could be getting finalized, which seems like it could manifest as above. If the loopback server waited for graceful shutdown, it would solve that. |
I tested with my loopback fix and it seems to fix this issue. |
Let's get it in. |
Reopening because we still need to re-enable the GetAsync_LargeHeader_Success test. I believe the underlying issue is fixed now, but we should verify that we don't see failures anymore here before re-enabling the test. |
Triage: probably fixed, re-enable, check if it reproduces or not. Either close or punt as a result. |
I've seen it (rarely) happening on
GetAsync_LargeHeader_Success
, but it is most probably a generic HTTP/3 test issue (I suspect LoopbackServer)Callstack shows
MsQuicStream.HandleEventConnectionClose
which means connection was closed while stream was in flight reading the response.This brings me to thing we've discussed today:
This exact issue manifests itself in our HTTP/3 tests, so we need to add some kind of app-level synchro there (or think of another solution).
The text was updated successfully, but these errors were encountered: