Avoid socket telemetry errors for pending nonblocking connects#129259
Avoid socket telemetry errors for pending nonblocking connects#129259tulior wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR updates sockets telemetry to avoid treating non-blocking Connect “pending” results (WouldBlock/InProgress) as failures, and adds a regression test ensuring the emitted connect Activity is not marked as an error in that scenario.
Changes:
- Adjust
SocketsTelemetry.AfterConnectto skip error status/tagging and failure counting for non-blocking connect pending errors. - Add a functional test covering non-blocking connects that initially return pending but ultimately succeed.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/libraries/System.Net.Sockets/tests/FunctionalTests/TelemetryTest.cs | Adds a new test validating telemetry Activity is not marked error for pending non-blocking connect. |
| src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketsTelemetry.cs | Avoids reporting WouldBlock/InProgress as connect failures in telemetry. |
13d0f09 to
c06bcd5
Compare
c06bcd5 to
c92a337
Compare
|
@tulior please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
Non-blocking Socket.Connect can return WouldBlock on Windows or InProgress on Unix while the OS connect attempt remains pending. Treat those results as pending telemetry states instead of failures. Leave the emitted connect Activity status unset, omit error.type, and avoid emitting ConnectFailed for these pending results. Add a regression test for the real synchronous Connect path so the pending result is verified through the public socket API.
9bea8f0 to
52e7103
Compare
Fixes #129252.
Non-blocking Socket.Connect can report WouldBlock on Windows or InProgress on Unix while the OS connect attempt remains pending. Sockets telemetry treated that result as a failure even though Connect has only reported a pending state.
This keeps the connect Activity, but leaves the status unset and omits error.type for pending results. It also suppresses the corresponding ConnectFailed EventSource event for the same pending states. Other SocketError values keep the existing failure path.
The EventSource part is included because it is the same pending-result case at the event layer. It can be separated if reviewers prefer to keep this PR scoped only to the experimental Activity surface.
This does not change the existing counter limitation: a pending connect that later succeeds is still not counted in outgoing-connections-established. Before this change it was not counted either; the pending result was reported as a failure instead.
The regression test covers the real synchronous Socket.Connect path for a non-blocking loopback connect. It asserts immediately after WouldBlock or InProgress because the Activity starts and stops inside Connect, so no later network completion is needed to verify the telemetry state.
Validation run locally on Windows:
dotnet.cmd build /t:Test /p:XunitMethodName=System.Net.Sockets.Tests.TelemetryTest.Connect_NonBlockingPending_ActivityNotMarkedAsErrordotnet.cmd build /t:Test /p:XUnitClassName=System.Net.Sockets.Tests.TelemetryTest