Fix WebSocket close single-consumer violation

[cittaz]

Summary

Fixes #121157 and the likely related #117267 tracking the same assertion.

Serializes the client-side RFC 6455 7.1.1 EOF wait behind _receiveMutex so the close path cannot issue a transport read while a pending receive is still reading from the same stream. This avoids the Http2Stream.TryReadFromBuffer Debug.Assert(!_hasWaiter) failure under concurrent CloseAsync plus pending ReceiveAsync scenarios over HTTP/2 (RFC 8441).

Root cause

WaitForServerToCloseConnectionAsync issues a _stream.ReadAsync for the RFC 6455 7.1.1 "client waits for server TCP close" step.

There are two ways the close handshake can reach that wait:

1. The receive loop observes the peer close frame in HandleReceivedCloseAsync. This path already runs while _receiveMutex is held.
2. The send-side close path sends our close frame after a peer close frame has already been observed. Previously this happened from SendCloseFrameAsync, which does not hold _receiveMutex.

A CAS-only guard avoids two completed calls to WaitForServerToCloseConnectionAsync, but it does not cover the wider race where the receive loop has already set _receivedCloseFrame and is still reading or parsing the close payload. In that window, SendCloseFrameAsync could observe _receivedCloseFrame and issue the EOF wait as a second read on the transport.

Over HTTP/1.1 the behavior is still wrong but historically tolerated by error handling. Over HTTP/2, Http2Stream.Http2ReadWriteStream enforces a single-consumer read invariant and can trip Debug.Assert(!_hasWaiter).

The supported scenario is called out in the class-level thread-safety contract:

/// - It's acceptable to have a pending ReceiveAsync while
///   CloseOutputAsync or CloseAsync is called.

Fix

Move the EOF wait out of SendCloseFrameAsync and into callers that can coordinate with the receive side:

• HandleReceivedCloseAsync still calls WaitForServerToCloseConnectionAsync while already holding _receiveMutex.
• CloseAsyncPrivate and CloseOutputAsyncCore acquire _receiveMutex before performing the EOF wait.
• CloseWithReceiveErrorAndThrowAsync already runs under _receiveMutex, so it bypasses CloseOutputAsyncCore and calls SendCloseFrameAsync directly to avoid re-entering the receive mutex.
• _waitedForServerClose remains as a one-shot guard so the EOF wait is not repeated sequentially if more than one close path reaches the completed handshake state.

Behavior preserved

• RFC 6455 7.1.1 "client waits for server TCP close" still runs at most once for a completed client close handshake.
• No public API change.
• No intended observable state-machine change.

Test-side comment clarification

The test that exercises this contract, RunClient_CloseAsync_DuringConcurrentReceiveAsync_ExpectedStates in CloseTest.cs, had a stale comment that misattributed where OperationCanceledException comes from in the abort branch. The comment now describes the acceptable outcomes and where the exception originates: ReceiveAsyncPrivate translates a stream exception to OperationCanceledException when _state == Aborted.

No test logic is changed.

Note for reviewers about work item visibility

I'm a community contributor and do not have access to the work-item logs for #121157 / #117267. I identified the likely failing path by reading the code:

• The stack trace in System.Net.WebSockets.Client.Tests: Assertion failed: !_hasWaiter #121157 narrows the failure to WaitForServerToCloseConnectionAsync running under Http2Stream.
• Combined with the "HTTP/2 WebSocket tests under Helix" context and the class-level thread-safety doc, the test CloseAsync_DuringConcurrentReceiveAsync_ExpectedStates under the CloseTest_*_Http2Loopback classes matches the scenario.

If a reviewer can confirm from the actual work-item logs that this test is the one triggering the assertion, I'll reference the run in this PR.

Local verification

Before the review update:

• Full libraries build (./build.cmd -subset libs -c Release): clean.
• System.Net.WebSockets.Client.Tests build: clean.
• Targeted test runs:
  • CloseTest_Invoker_Http2Loopback.CloseAsync_DuringConcurrentReceiveAsync_ExpectedStates (both useSsl values)
  • CloseTest_HttpClient_Http2Loopback.CloseAsync_DuringConcurrentReceiveAsync_ExpectedStates (both useSsl values)
  • Full CloseTest* regression run (no new failures)

The latest receive-mutex follow-up was reviewed locally but not re-run.

[dotnet-policy-service]

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

[MihaZupan]

Thank you for looking into this!
I don't think the current change is a complete fix.

[MihaZupan]

I don't think this is a sufficient fix. From reading the code, there's a potentially large race condition window here where we've set _receivedCloseFrame but are still reading from the receive side, e.g. here before we call into WaitForServerToCloseConnectionAsync:

runtime/src/libraries/System.Net.WebSockets/src/System/Net/WebSockets/ManagedWebSocket.cs

Lines 1086 to 1089 in 1d02af4

	if (_receiveBufferCount < header.PayloadLength)
	{
	await EnsureBufferContainsAsync((int)header.PayloadLength, cancellationToken).ConfigureAwait(false);
	}

If the receive loop is busy in that EnsureBufferContainsAsync call, the SendCloseFrameAsync will issue a 2nd read on the transport.

---

I think a better fix would be to ensure that WaitForServerToCloseConnectionAsync is only called after the caller has acquired the read lock.
As you've called out already:

• When called from the receive side, it's while we're holding the mutex.
• When called from the send side, we're not ensuring that right now.
  

  runtime/src/libraries/System.Net.WebSockets/src/System/Net/WebSockets/ManagedWebSocket.cs

  Lines 1564 to 1567 in 1d02af4

  	if (!_isServer && _receivedCloseFrame)
  	{
  	await WaitForServerToCloseConnectionAsync(cancellationToken).ConfigureAwait(false);
  	}

[cittaz]

Hi @MihaZupan,

You're right about the second edge case. I missed that part.

Acquiring _receiveMutex on that code path needs a bit more code to avoid re-entering the receive lock, so I pushed a follow-up change that moves the EOF wait out of SendCloseFrameAsync and into callers that can coordinate with the receive side.

I still kept _waitedForServerClose, since it avoids running the EOF wait twice sequentially. That case would not hit the HTTP/2 single-reader assertion anymore, but it could still waste up to 1 second on a duplicate wait.

Whenever you have time, could you re-review it?

Also, while digging into this, the close handling started feeling a bit non-intuitive to me, and I think there may be a second, separate behavior worth clarifying: messages can be consumed by CloseAsyncPrivate while it is waiting for the close frame inside CloseAsyncPrivate:

// Loop until we've received a close frame.
while (!_receivedCloseFrame)
{
    ...
    receiveTask = ReceiveAsyncPrivate<ValueWebSocketReceiveResult>(closeBuffer, cancellationToken);
    ...
}

The loop calls ReceiveAsyncPrivate into a local closeBuffer until _receivedCloseFrame is set. Any data frames the peer sends in the meantime get consumed by that internal receive and are not surfaced to the user. So if a user has a pending ReceiveAsync when CloseAsync is called, whether they observe those last frames depends on which receive loop wins the race.

I noticed the existing tests already point users toward CloseOutputAsync when they want to send a close frame and still receive data, and RFC 6455 section 5.5.1 also says there is no guarantee that an endpoint that has already sent a Close frame will continue to process data. So I'm not sure whether this current CloseAsync behavior is intentional and correct.

The part that still gives me some doubt is the class-level remark at ManagedWebSocket.cs#L25:

/// - It's acceptable to have a pending ReceiveAsync while CloseOutputAsync or CloseAsync is called.

To me, "acceptable" reads as "supported and observable", but I'm not sure whether that interpretation is too strong for CloseAsync specifically.

Do you think the current behavior is intentional/correct? If it is, do you think it would be worth documenting or covering directly with a test? I'd be happy to keep this PR scoped down to the immediate fix you suggested in the meantime.

Thanks for the careful review!