QUIC: SHUTDOWN_INITIATED_BY_TRANSPORT on connection should not result in QuicOperationAbortedException

[geoffkizer]

SHUTDOWN_INITIATED_BY_TRANSPORT can indicate a variety of different errors, including stateless reset or a QUIC protocol error. It's determined locally by MsQuic (hence the name).

Currently, if we receive SHUTDOWN_INITIATED_BY_TRANSPORT from MsQuic, we generate a QuicOperationAbortedException for any attempted operations on the connection (e.g. AcceptStreamAsync).

This seems like the wrong exception. QuicOperationAbortedException is intended to mean that the local user closed the connection, and thus the outstanding operation was aborted as a result.

We could use QuicConnectionAbortedException here, except that this requires an error code, and is intended for cases where the peer explicitly closed the connection, so it doesn't seem ideal.

We probably need a new exception type for this. And we may want to distinguish different error cases within this.

[ghost]

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

Issue Details

---

SHUTDOWN_INITIATED_BY_TRANSPORT can indicate a variety of different errors, including stateless reset or a QUIC protocol error. It's determined locally by MsQuic (hence the name).

Currently, if we receive SHUTDOWN_INITIATED_BY_TRANSPORT from MsQuic, we generate a QuicOperationAbortedException for any attempted operations on the connection (e.g. AcceptStreamAsync).

This seems like the wrong exception. QuicOperationAbortedException is intended to mean that the local user closed the connection, and thus the outstanding operation was aborted as a result.

We could use QuicConnectionAbortedException here, except that this requires an error code, and is intended for cases where the peer explicitly closed the connection, so it doesn't seem ideal.

We probably need a new exception type for this. And we may want to distinguish different error cases within this.

Author:	geoffkizer
Assignees:	-
Labels:	area-System.Net.Quic
Milestone:	6.0.0

[wfurt]

can we reliably detect the reason?
cc: @nibanks

[nibanks]

can we reliably detect the reason?
cc: @nibanks

The event does give you a status code. It might not always clearly differentiate all possible reasons, but if you ever need more, we can add more specific status codes.

[karelz]

Triage: QUIC does not have direct users. Unless ASP.NET needs this, it is not critical for 6.0. Moving to 7.0 for now.

[karelz]

Triage: This should be fixed - @ManickaP can you please verify (for extra points :))

[ManickaP]

This has been partially fixed for 6.0 (and main as well) in #60181, i.e. it's a hack solution to cause a minimal churn.
We still need to decide the proper way to surface the difference between peer application close and transport close. Either by a different exception or a different property on an existing one.
The 7.0 milestone stands, this should be solved together with the general "exceptions" discussion.

[karelz]

Triage: @rzikm drives exception design, should be part of that.

[karelz]

Duplicate of #70669