Normal operations inner exceptions of ManagedWebsocket lead to big percentage of all thrown exceptions

[petrroll]

Description

Any big websocket service will naturally have clients suddenly disconnecting, sending cancelled, etc. There's almost no way to proactively guard from it. Current design of .NET BCL means this events lead to exception. That much is expected.

Even if one tries to proactively limit the number of actually thrown exceptions via configureoptions SuppressThrowing, there's still a lot of exceptions thrown within the ManagedWebSocket for control flow.

Namely we see following callstacks (most often ReceiveAsyncPrivate):

Configuration

Windows, http.sys, .NET 9; but it seems to be not tied to either platform of http server.

Regression?

No

Data

See above

Ask:

I understand big changes might be problematic, but wouldn't it be possible to change ReceiveAsyncPrivate to do controll flow without throwin (and frequently catching) exceptions? But instead just return?

Analysis

Exceptions above are > 10 % of all exceptions thrown in our (very big) websocket as a service service (hundreds of millions users daily).

[dotnet-policy-service]

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

[CarnaViire]

Triage: as discussed offline with @petrroll, the perf implications of this is negligible, given the connection's lifetime (several hours) and this only happening when the connection is torn down. Same is true for preventing all exceptions from firing in general.

At the same time, there are some inconsistencies in the WS codebase over

• letting an exception bubble up (synchronously) vs catching and returning it wrapped into a value task;
• throwing a just-created exception (only to be later caught and wrapped) vs returning it to be wrapped directly.

It would be nice to unify the approaches (or leave a short comment if there is a strong reason to choose one over another) in Future.