Ignore LoopbackServer exceptions in MaxHeadersLength test

[MihaZupan]

Fixes #73930

[ghost]

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

Issue Details

---

Fixes #73930

Author:	MihaZupan
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	7.0.0

[ManickaP]

LGTM, thanks. Small suggestion.

[MihaZupan]

The test is failing with "inactivity" on both client and server side (console logs):

System.Net.Quic.QuicException: The connection timed out from inactivity.

It also hit an Assert with no message that I can't find anywhere near the reported line in Http3Connection.

I don't see a reason why both sides would be hanging on this specific test.
It seems like it could be a product issue (or at least an issue with the loopback server).
cc: @ManickaP @CarnaViire @rzikm

I will disable this specific test for H3 for now instead to clean up CI.

---

Even this fails:
https://github.com/dotnet/runtime/blob/2a2f6732fc86c7665fb317d60fe178aa3b619200/src/libraries/Common/tests/System/Net/Http/HttpClientHandlerTest.MaxResponseHeadersLength.cs#L52-L61

[ManickaP]

Based on the console logs, in both cases the server is waiting on data on the control stream:

at System.Net.Quic.ResettableValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token) in /_/src/libraries/System.Net.Quic/src/System/Net/Quic/Internal/ResettableValueTaskSource.cs:line 267
at System.Net.Quic.QuicStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken) in /_/src/libraries/System.Net.Quic/src/System/Net/Quic/QuicStream.cs:line 287
at System.Net.Test.Common.Http3LoopbackStream.ReadIntegerAsync() in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackStream.cs:line 462
at System.Net.Test.Common.Http3LoopbackConnection.<EnsureControlStreamAcceptedAsync>g__EnsureControlStreamAcceptedInternalAsync|39_0() in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackConnection.cs:line 149
at System.Net.Test.Common.Http3LoopbackConnection.AcceptRequestStreamAsync() in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackConnection.cs:line 165
at System.Net.Test.Common.Http3LoopbackConnection.HandleRequestAsync(HttpStatusCode statusCode, IList`1 headers, String content) in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackConnection.cs:line 231
at System.Net.Test.Common.Http3LoopbackServer.HandleRequestAsync(HttpStatusCode statusCode, IList`1 headers, String content) in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackServer.cs:line 93
at System.Net.Test.Common.Http3LoopbackServer.HandleRequestAsync(HttpStatusCode statusCode, IList`1 headers, String content) in /_/src/libraries/Common/tests/System/Net/Http/Http3LoopbackServer.cs:line 93
at System.Net.Http.Functional.Tests.HttpClientHandler_MaxResponseHeadersLength_Test.<>c__DisplayClass4_0.<<LargeSingleHeader_ThrowsException>b__1>d.MoveNext() in /_/src/libraries/Common/tests/System/Net/Http/HttpClientHandlerTest.MaxResponseHeadersLength.cs:line 88

That's why everything times out, server won't reply until it read the settings frame from the control stream.

The process killing Assert comes from OpenOutboundStream and is for Bidirectional stream, so it's not that.

No-merge until the tests are actually fixed

[MihaZupan]

System.Net.Quic.QuicException: An internal error has occurred. Status code: QUIC_STATUS_SUCCESS

😆

console logs

[CarnaViire]

Note exit code 134 😭
Linking #72696 just in case
Was it happening on other runs as well? @MihaZupan

[ManickaP]

The SUCCESS status comes from this line: (shutdownByApp: false, closedRemotely: false) => ThrowHelper.GetExceptionForMsQuicStatus(data.ConnectionCloseStatus), Either there's a data corruption or we have bad/old msquic version, or there's a bug in msquic.
cc @rzikm since you added this recently.

[MihaZupan]

This is the first time I've seen that specific failure.
In other runs, it's been System.Net.Quic.QuicException: The connection timed out from inactivity.

[rzikm]

cc @rzikm since you added this recently.

I am trying to setup alpine wsl so I can take a look at the dump, but the source suggests that we receive the success status from MsQuic

[rzikm]

Assert should be fixed by #74348

[MihaZupan]

Not getting much use out of running CI here, closing for now.