Test failure: SendAsync_SlowServerRespondsAfterDefaultReceiveTimeout_ThrowsHttpRequestException

[stephentoub]

https://ci.dot.net/job/dotnet_corefx/job/master/job/outerloop_windows_nt_debug_prtest/148/consoleText
https://ci.dot.net/job/dotnet_corefx/job/master/job/outerloop_windows_nt_debug_prtest/147/consoleText

System.Net.Http.WinHttpHandlerFunctional.Tests.WinHttpHandlerTest.SendAsync_SlowServerRespondsAfterDefaultReceiveTimeout_ThrowsHttpRequestException [FAIL]
        Assert.Throws() Failure
        Expected: typeof(System.AggregateException)
        Actual:   (No exception was thrown)
        Stack Trace:
           D:\j\workspace\outerloop_win---7ad0ce03\src\System.Net.Http.WinHttpHandler\tests\FunctionalTests\WinHttpHandlerTest.cs(109,0): at System.Net.Http.WinHttpHandlerFunctional.Tests.WinHttpHandlerTest.SendAsync_SlowServerRespondsAfterDefaultReceiveTimeout_ThrowsHttpRequestException()

[karelz]

cc @Priya91 @ianhays @steveharter

[davidsh]

This test is never going to be 100% reliable in CI. In general, testing cancellation is problematic because cancellation is "cooperative" and not guaranteed. So, in some cases when the CI machine is busy, it might be possible for the cancellation request to take longer than the actual HTTP request. Which means the request succeeds and thus the test fails because the request was not cancelled.

[stephentoub]

Why can't it just go against a loopback page that never finishes the request? Then cancellation/timeout can be issued at any point after we issue it. In fact we already have such a test:
https://github.com/dotnet/corefx/blob/09f9d0beb74fa254e9e26e246ee81ce0a263eeda/src/System.Net.Http/tests/FunctionalTests/CancellationTest.cs#L31

[stephentoub]

Again:
https://ci.dot.net/job/dotnet_corefx/job/master/job/outerloop_windows_nt_debug_prtest/150/

[davidsh]

Why can't it just go against a loopback page that never finishes the request? Then cancellation/timeout can be issued at any point after we issue it. In fact we already have such a test:

That could be an option. I had previously thought the WinHttpHandlerTest was already against a loopback server.

[stephentoub]

Do we need this WinHttpHandler-specific test at all, since the test I linked to would seem to cover the same functionality?

[davidsh]

Do we need this WinHttpHandler-specific test at all, since the test I linked to would seem to cover the same functionality?

WinHttpHandler.ReceiveTimeout is different from HttpClient.Timeout. In fact, when HttpClient uses HttpClientHandler, it internally sets all the WinHttpHandler timeouts to "infinite". The cancellation mechansim is very different in the HttpClient.TImeout test compared to WinHttpHandler.ReceiveTimeout

If we want good code coverage of the WinHttpHandler specific properties, then we need this test in some way.

[stephentoub]

I see, I didn't notice it was a different timeout property. In that case the test we have could be duplicated and modified.

[karelz]

Given that this is test issue only and that the product actually works and that we do not have infinite time, moving to Future. It would be still nice to have it fixed in 2.0.

@hughbe are you interested? ;-)

[ManickaP]

Triage: fix the test as suggested above.

[liveans]

It's still failing after the change, (6 occurrences (2 fail, 4 pass on rerun)).
Reopening for further investigation

[liveans]

Duplicate of #96481