Fix WinHttpRequest destructor hang when the request context is never bound

[Dan Cristoloveanu (dcristoloveanu)]

Fixes #7352

Problem

WinHttpRequest::~WinHttpRequest() closes the request handle and then waits for
WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING before returning. That barrier is deliberate and
necessary: WinHTTP is used in async mode (WINHTTP_FLAG_ASYNC), the callback context is a raw
pointer to the WinHttpAction owned by the request, and the callback also dereferences
m_httpRequest. Returning before HANDLE_CLOSING would let a WinHTTP worker thread touch freed
memory.

However, WinHttpAction::StatusCallback() discards every notification that arrives with
dwContext == 0, and the context is bound to the handle only by WinHttpSendRequest() — while
the status callback is registered much earlier, at the end of the constructor. Any request
destroyed in between (for example when an exception is thrown while preparing headers or querying
the body stream length) therefore closes its handle, receives HANDLE_CLOSING with no context, has
it dropped, and blocks in WaitForAction forever. The wait uses a default-constructed
Azure::Core::Context, so ThrowIfCancelled() never fires and the poll loop spins indefinitely —
the thread is lost for the lifetime of the process.

CompleteActionWithError() intentionally does not signal while waiting for HANDLE_CLOSING, so
the REQUEST_ERROR / ERROR_WINHTTP_OPERATION_CANCELLED notification that WinHTTP raises when
closing a handle with a pending operation does not release the waiter either.

This is the hang that remains in the window #6637 addressed for the FailFast case; that PR's own
comment already observes that "the initiateAction call is a call to WinHttpSendRequest which
establishes the SendContext".

Fix

Bind the context to the request handle in the constructor with
WinHttpSetOption(WINHTTP_OPTION_CONTEXT_VALUE, ...), immediately before registering the status
callback. HANDLE_CLOSING is then always delivered with a valid context, so the destructor's
barrier always completes. WinHttpSendRequest() continues to pass the same value, which is
idempotent.

The barrier itself is unchanged — the fix makes it satisfiable rather than removing it.

Alternatives considered

• Track whether the context was bound and skip the wait when it was not. Safe for the same
  reason the bug exists (with no context every callback is already dropped, so there is nothing to
  synchronize against), but smaller in scope and leaves HANDLE_CLOSING unobservable.
• Give the destructor's wait a deadline. Rejected: abandoning the wait permits a WinHTTP worker
  thread to invoke the callback after WinHttpAction/WinHttpRequest are destroyed, converting a
  hang into a use-after-free.
• Signal the event from CompleteActionWithError() during close. Rejected for the same reason:
  it would release the waiter before HANDLE_CLOSING, which is precisely what the barrier prevents.

Test

sdk/core/azure-core/test/ut/win_http_transport_test.cpp adds
WinHttpTransport.RequestThatFailsDuringSetupDoesNotHang.

SendRequest() calls request.GetBodyStream()->Length() before WinHttpSendRequest(), and
BodyStream::Length() is not noexcept, so a body stream that throws from Length() enters the
window deterministically. The test needs no network: WinHttpOpen(), WinHttpConnect() and
WinHttpOpenRequest() only allocate handles, and the request fails before anything is sent.

The work runs on a detached thread guarded by a 30 s future wait, so a regression fails the test
instead of hanging the CI run (a blocked destructor cannot be joined).

Verified against the vendored 1.16.3 sources in a downstream consumer: an equivalent test hangs
and fails on the 30 s timeout without the product change, and passes in 0.76 s with it. A leak
checker also reported the abandoned WinHttpRequest from
WinHttpTransportImpl::CreateRequestHandle() before the fix, and no leaks after.

The full CI matrix is green on this PR, including the Win2022_Win32Api_debug_tests_winhttp_x64
and x86 legs that build and run the new test.

Pull Request Checklist

• C++ Guidelines
• Doxygen docs — n/a, no public API change
• Unit tests
• No unwanted commits/changes
• Descriptive title/description
  • PR is single purpose
  • Related issue listed
• Comments in source
• No typos
• Update changelog
• Not work-in-progress — opened as a draft for maintainer feedback on the approach
• External references or docs updated
• Self review of PR done
• Any breaking changes? — none; behavior only changes in the case that previously hung

---

_{Authored with GitHub Copilot CLI — session ID 6afdad25-6ece-4e65-991c-aa8d88d138fa}

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
8 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
8 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR fixes a WinHTTP adapter teardown deadlock in azure-core where WinHttpRequest::~WinHttpRequest() could block forever if the request is destroyed before WinHttpSendRequest() associates the callback context with the request handle. The change ensures the destructor’s existing “wait for WINHTTP_CALLBACK_STATUS_HANDLE_CLOSING” barrier is always satisfiable, and adds a unit test to prevent regressions.

Changes:

• Bind the WinHTTP context value in WinHttpRequest construction via WinHttpSetOption(WINHTTP_OPTION_CONTEXT_VALUE, ...) before registering the status callback.
• Add a WinHTTP-focused unit test that deterministically throws during request setup (before WinHttpSendRequest) and asserts the call returns (does not hang).
• Wire the new test file into the azure-core unit test target.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
sdk/core/azure-core/src/http/winhttp/win_http_transport.cpp	Sets WINHTTP_OPTION_CONTEXT_VALUE during request construction so HANDLE_CLOSING callbacks always have a valid context and the destructor barrier can complete.
sdk/core/azure-core/test/ut/win_http_transport_test.cpp	Adds WinHttpTransport.RequestThatFailsDuringSetupDoesNotHang regression test covering the pre-WinHttpSendRequest failure window.
sdk/core/azure-core/test/ut/CMakeLists.txt	Includes the new WinHTTP transport unit test source in the test executable build.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.