Skip to content
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

Don't log datagrams failed to send/receive #40083

Conversation

alnikola
Copy link
Contributor

Socket's telemetry incorrectly logs datagrams as being sent or received even if the operation failed. This PR fixes it.

@ghost
Copy link

ghost commented Jul 29, 2020

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

@alnikola alnikola added this to the 5.0.0 milestone Jul 29, 2020
Copy link
Member

@antonfirsov antonfirsov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but I'm wondering why don't we have test changes in this PR?

Isn't it a requirement for the telemetry feature that both positive and negative cases are well-tested?

@@ -1180,8 +1180,7 @@ public int Send(IList<ArraySegment<byte>> buffers, SocketFlags socketFlags, out
// Don't log transfered byte count in case of a failure.
return 0;
}

if (SocketsTelemetry.Log.IsEnabled())
else if (SocketsTelemetry.Log.IsEnabled())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgive me my stupid question, but how does the else if instead of just if here helps? If the previous block ends with return.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it uniformly in all cases for the sake of a higher readability. There are other places without return inside the if (errorCode != SocketError.Success), but we still don't want to log anything there in case of a failure. (one example)

@alnikola
Copy link
Contributor Author

@antonfirsov It would be unreasonably hard to cover all possible telemetry calls with tests, and even if we did it, tests would be extremely fragile since telemetry calls can be added/moved around over time in different places.

@alnikola
Copy link
Contributor Author

/azp run runtime-libraries outerloop

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@alnikola alnikola merged commit 278cc96 into dotnet:master Jul 30, 2020
@alnikola alnikola deleted the alnikola/sockets-count-transf-bytes-in-failures branch July 30, 2020 14:43
Jacksondr5 pushed a commit to Jacksondr5/runtime that referenced this pull request Aug 10, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants