-
Notifications
You must be signed in to change notification settings - Fork 10.3k
[Named pipes] Disconnect + delayed client read test cases #46166
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
[Named pipes] Disconnect + delayed client read test cases #46166
Conversation
… is disposed earlier than the next client read happens Signed-off-by: Simon Ferquel <[email protected]>
Thanks for your PR, @simonferquel. Someone from the team will get assigned to your PR shortly and we'll get it reviewed. |
src/Servers/Kestrel/Transport.NamedPipes/test/NamedPipeConnectionListenerTests.cs
Outdated
Show resolved
Hide resolved
src/Servers/Kestrel/Transport.NamedPipes/test/NamedPipeConnectionListenerTests.cs
Outdated
Show resolved
Hide resolved
The test actually revealed an error case on Linux it seems:
On Linux it seems the write call does complete immediately, and the exception raised on the read task is not catched (it is a bit surprising to see a Cancelled exception wrapped in an IOException). I'll make a fix for that in that PR. |
This actually seem to be a test error, with an assertion failing because on Linux, from the server side the Write call is not blocking, but the read from the client side actually succeeds. |
Signed-off-by: Simon Ferquel <[email protected]>
Signed-off-by: Simon Ferquel <[email protected]>
Signed-off-by: Simon Ferquel <[email protected]>
I excluded the tests on Linux and macOS. I think we'll disable using the named pipes transport outside of Windows: #46231 |
Makes sense yes |
[Named pipes] Disconnect + delayed client read test cases
Description
Adds tests in Named Pipes support to check that the client won't miss last bytes written to the pipe, if
NamedPipeConnection::Transport.Output.Complete()
orNamedPipeConnection::Transport.Output.DisposeAsync()
is called before the last client-side Read happens.Luckily, with current implementation, PipeOptions.WriteThrough make sure the Read happens before exiting the SendLoop. The introduced tests here are there to make sure this does not regress.
contributes to #14207