Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Write_HeadersToClosedConnectionSynchronously_ThrowsHttpListenerException test fails on macOS #21590

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

Open
stephentoub opened this issue May 9, 2017 · 7 comments
Labels
area-System.Net backlog-cleanup-candidate An inactive issue that has been marked for automated closure. disabled-test The test is disabled in source code against the issue no-recent-activity os-mac-os-x macOS aka OSX test-run-core Test failures in .NET Core test runs
Milestone

Comments

@stephentoub
Copy link
Member

System.Net.Tests.HttpResponseStreamTests.Write_HeadersToClosedConnectionSynchronously_ThrowsHttpListenerException(ignoreWriteExceptions: False) [FAIL]
10:29:33         Assert.Throws() Failure
10:29:33         Expected: typeof(System.Net.HttpListenerException)
10:29:33         Actual:   (No exception was thrown)
10:29:33         Stack Trace:
10:29:33            /Users/dotnet-bot/j/workspace/dotnet_corefx/master/osx10.12_release_prtest/src/System.Net.HttpListener/tests/HttpResponseStreamTests.cs(453,0): at System.Net.Tests.HttpResponseStreamTests.<Write_HeadersToClosedConnectionSynchronously_ThrowsHttpListenerException>d__21.MoveNext()
10:29:33            --- End of stack trace from previous location where exception was thrown ---
10:29:33               at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
10:29:33               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
10:29:33            --- End of stack trace from previous location where exception was thrown ---
10:29:33               at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
10:29:33               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
10:29:33            --- End of stack trace from previous location where exception was thrown ---
10:29:33               at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
10:29:33               at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
@Priya91
Copy link
Contributor

Priya91 commented May 10, 2017

This test is disabled here with #20997

@Priya91
Copy link
Contributor

Priya91 commented May 10, 2017

Closing as dupe.

@Priya91 Priya91 closed this as completed May 10, 2017
@stephentoub
Copy link
Member Author

Several tests are [ActiveIssue(...)]'d against this, e.g.

[ActiveIssue("https://github.com/dotnet/corefx/issues/19534", TestPlatforms.OSX)]
[ConditionalTheory(typeof(PlatformDetection), nameof(PlatformDetection.IsNotWindowsSubsystemForLinux))] // [ActiveIssue("https://github.com/dotnet/corefx/issues/11057")]
[InlineData(true)]
[InlineData(false)]
[ActiveIssue("https://github.com/dotnet/corefx/issues/18188", platforms: TestPlatforms.Windows)] // Indeterminate failure - socket not always fully disconnected.
public async Task Write_ContentToClosedConnectionSynchronously_ThrowsHttpListenerException(bool ignoreWriteExceptions)

@stephentoub stephentoub reopened this Jan 23, 2020
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@karelz karelz added the test-run-core Test failures in .NET Core test runs label Feb 23, 2020
@karelz karelz modified the milestones: 2.0.0, 5.0 Feb 23, 2020
@karelz karelz modified the milestones: 5.0, Future May 7, 2020
@wfurt
Copy link
Member

wfurt commented Oct 24, 2020

I tried it on macOS and I it seems to work now. But it is inheritently unreliable and disabled on Windows as well. I think it works on Linux only by good luck.

The test closes client side and depends on "abortive" behavior. When the Close in WaitForSocketShutdown() is finished, there is no guarantee that the server actually processed the RST and that the socket in closed state.
I tried to replace it with Shutdown() and see if I can detect server closely but that does not happen since the test is still holding the OutputStream. We would probably need some reflection and inner state knowledge to know the close was actually processed by the server.

We could add some arbitraty delay but that still seems problematic.
Since I do not see path forward I'm suggesting to delete the test and close this issue.
We could alternatively make it Linux specific and remove the ActivreIssues.

please cast your vote @stephentoub @geoffkizer

I think #21940 is on the same boat using exactly same strategy. I just don't see value keeping those old issues open.

@geoffkizer
Copy link
Contributor

I vote delete

@stephentoub
Copy link
Member Author

Sounds fine

Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Apr 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Net backlog-cleanup-candidate An inactive issue that has been marked for automated closure. disabled-test The test is disabled in source code against the issue no-recent-activity os-mac-os-x macOS aka OSX test-run-core Test failures in .NET Core test runs
Projects
None yet
Development

No branches or pull requests

6 participants