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

[release/8.0-staging] remove extra assert from WinHttp handler #112861

Open
wants to merge 2 commits into
base: release/8.0-staging
Choose a base branch
from

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Feb 24, 2025

Backport of #93984 to release/8.0-staging

Fixes #93099
Fixes #104891
Fixes #112700

/cc @ManickaP @wfurt

Customer Impact

Discovered in our CI, the issue is fixed since .NET 9. The problem is that from a certain Windows version, we strongly suspect WinHTTP switched to TLS 1.3 by default and hit new code paths, which ends up in NullReferenceException, making most/all our WinHTTP tests to crash.

Technical details: We see that our callback from WinHTTP is sometimes called twice. Therefore, we changed code to detect such situation by checking argument RequestHandle for NULL. Technically, the change just swaps assert for if not null.

Regression

No (at least not in our code).

Testing

CI run confirmed that WinHttpHandler tests do not crash.

Risk

Low. Firstly, this fix is out in 9.0 and 10.0. Secondly, it's very small change replacing assert with if not null.

Copy link
Contributor

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

@karelz
Copy link
Member

karelz commented Feb 25, 2025

This heavily impacts our test runs in 8.0.x. The fix is already in 9 and 10, with minimal change - we should take it to unblock WinHTTP test runs in 8.0.x.

@ManickaP ManickaP requested a review from a team February 25, 2025 14:39
Copy link
Member

@rzikm rzikm left a comment

Choose a reason for hiding this comment

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

Code changes LGTM, though I am not 100% sure if the csproj changes (I never serviced OOB package)

@@ -4,8 +4,8 @@
<IncludeDllSafeSearchPathAttribute>true</IncludeDllSafeSearchPathAttribute>
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
<IsPackable>true</IsPackable>
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
Copy link
Member

Choose a reason for hiding this comment

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

@carlossanlop is this the right way to do it? I made the changes based on this: 09784cd

Copy link
Member

Choose a reason for hiding this comment

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

Yes, that's correct.

@ManickaP ManickaP self-assigned this Mar 6, 2025
@carlossanlop
Copy link
Member

@ManickaP @wfurt @karelz Today is code complete for the April Release. If you want this fix included in this release, please get it approved by Tactics and merge it before 4pm PT.

@ManickaP
Copy link
Member

@carlossanlop could you please help me make sure I'm doing the versioning correctly here: #112861 (comment)

This is not an urgent fix, so it's ok if we slipped the deadline. I'll ping the tactics once I have the above mentioned comment resolved.

@ManickaP
Copy link
Member

/azp run runtime

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@ManickaP
Copy link
Member

/ba-g infrastructure issue dotnet/dnceng#5144

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Net Servicing-consider Issue for next servicing release review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants