-
Notifications
You must be signed in to change notification settings - Fork 10.9k
Avoid unobserved tasks in WebSocketsTransport #12315
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -156,6 +156,9 @@ private async Task ProcessSocketAsync(WebSocket socket) | |
|
|
||
| if (trigger == receiving) | ||
| { | ||
| // Observe exception if there is one to avoid unobserved tasks | ||
| _ = receiving.Exception; | ||
|
|
||
| // We're waiting for the application to finish and there are 2 things it could be doing | ||
| // 1. Waiting for application data | ||
| // 2. Waiting for a websocket send to complete | ||
|
|
@@ -176,13 +179,19 @@ private async Task ProcessSocketAsync(WebSocket socket) | |
| } | ||
| else | ||
| { | ||
| // Observe exception if there is one to avoid unobserved tasks | ||
| _ = sending.Exception; | ||
|
|
||
| // Cancel the timeout | ||
| delayCts.Cancel(); | ||
| } | ||
| } | ||
| } | ||
| else | ||
| { | ||
| // Observe exception if there is one to avoid unobserved tasks | ||
| _ = sending.Exception; | ||
|
|
||
| // We're waiting on the websocket to close and there are 2 things it could be doing | ||
| // 1. Waiting for websocket data | ||
| // 2. Waiting on a flush to complete (backpressure being applied) | ||
|
|
@@ -269,10 +278,6 @@ private async Task StartReceiving(WebSocket socket) | |
| if (!_aborted) | ||
| { | ||
| _application.Output.Complete(ex); | ||
|
|
||
| // We re-throw here so we can communicate that there was an error when sending | ||
| // the close frame | ||
| throw; | ||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the main culprit for unobserved tasks. An alternative solution would be to keep this and actually observe the exception and set a private field to let the send loop know to send an internal server error instead of possibly a normal exit code. |
||
| } | ||
| } | ||
| finally | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't these exceptions matter? Should we at least be logging them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably should, but to no higher than
Debugsince they will include client disconnects.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug ftw
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should never actually have exceptions in them, I was just being paranoid. We have a try catch around both sending and receiving so the only exceptions that could escape would be Pipe.Complete throwing, logger throwing, or
socket.CloseOutputAsync(this would be the one most likely to throw).I'll just wrap
socket.CloseOutputAsyncand log it if it throws.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get rid of all the
_ = blah.Exceptionlines then?The mere existence of these lines communicates to other developers that these tasks could have completed with an exception. I don't want to risk seeing this pattern copied more widely. The more places this pattern is used, the more likely it will be copied somewhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm good with removing them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool. If for whatever reason we are still concerned about something unexpected throwing, we could also replace the
_ = blah.Exceptionwithawait trigger. That way if there was an unexpected error, WebSocketTransport.StopAsync() would rethrow it.