`QuicConnection.DisposeAsync` throws `OperationCanceledException`

[bentoi]

Description

The attached test case demonstrates that QuicConnection.DisposeAsync throws OperationCanceledException.

Also, looking at the implementation of QuicConnection.DisposeAsync, DisposeAsync is not a silent close as described by the documentation. It's a graceful close that sends a close frame with the DefaultCloseErrorCode.

This also raises the question of what DisposeAsync should do if CloseAsync is canceled.

Reproduction Steps

Run the attach program with a Kestrel server.

quic-client.zip

Expected behavior

operation canceled

Actual behavior

operation canceled
Unhandled exception. System.OperationCanceledException: The operation was canceled.
   at System.Net.Quic.ValueTaskSource.TryComplete(Exception exception)
   at System.Net.Quic.ValueTaskSource.<>c.<TryInitialize>b__10_0(Object obj, CancellationToken cancellationToken)
   at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
   at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
   at System.Threading.TimerQueue.FireNextTimers()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
--- End of stack trace from previous location ---
   at System.Net.Quic.ValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Quic.QuicConnection.DisposeAsync()
   at Program.Main(String[] args) in /home/vagrant/workspace/quic-client/Program.cs:line 35
   at Program.Main(String[] args) in /home/vagrant/workspace/quic-client/Program.cs:line 35
   at Program.<Main>(String[] args)

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

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

Issue Details

---

Description

The attached test case demonstrates that QuicConnection.DisposeAsync throws OperationCanceledException.

Also, looking at the implementation of QuicConnection.DisposeAsync, DisposeAsync is not a silent close as described by the documentation. It's a graceful close that sends a close frame with the DefaultCloseErrorCode.

This also raises the question of what DisposeAsync should do if CloseAsync is canceled.

Reproduction Steps

Run the attach program with a Kestrel server.

quic-client.zip

Expected behavior

operation canceled

Actual behavior

operation canceled
Unhandled exception. System.OperationCanceledException: The operation was canceled.
   at System.Net.Quic.ValueTaskSource.TryComplete(Exception exception)
   at System.Net.Quic.ValueTaskSource.<>c.<TryInitialize>b__10_0(Object obj, CancellationToken cancellationToken)
   at System.Threading.CancellationTokenSource.ExecuteCallbackHandlers(Boolean throwOnFirstException)
   at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool)
   at System.Threading.TimerQueue.FireNextTimers()
   at System.Threading.ThreadPoolWorkQueue.Dispatch()
   at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
--- End of stack trace from previous location ---
   at System.Net.Quic.ValueTaskSource.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Quic.QuicConnection.DisposeAsync()
   at Program.Main(String[] args) in /home/vagrant/workspace/quic-client/Program.cs:line 35
   at Program.Main(String[] args) in /home/vagrant/workspace/quic-client/Program.cs:line 35
   at Program.<Main>(String[] args)

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	bentoi
Assignees:	-
Labels:	untriaged, area-System.Net.Quic
Milestone:	-

[ManickaP]

The attached test case demonstrates that QuicConnection.DisposeAsync throws OperationCanceledException.

I'm not able to reproduce this, the connection gets shut down without any exception. But based on the output you report and the code, we keep the original exception from CloseAsync and re-report it in DisposeAsync. That is a bug that needs to be fixed.

Also, looking at the implementation of QuicConnection.DisposeAsync, DisposeAsync is not a silent close as described by the documentation. It's a graceful close that sends a close frame with the DefaultCloseErrorCode.

This is a fault in the docs. The behavior was changed at the last moment based on the API review feedback, so I probably overlooked the comments from which the docs are generated. I'll fix this.

This also raises the question of what DisposeAsync should do if CloseAsync is canceled.

We could recognize this particular case and issue a silent Shutdown instead. I.e.: DisposeAsync would have these 3 different behaviors:

1. CloseAsync was called and succeeded --> don't call msquic Shutdown since it has already been processed and just release the resources (same as now)
2. CloseAsync was called and failed --> call msquic Shutdown with SILENT flag which should report SHUTDOWN_COMPLETE immediately and then release the resources as usual (new behavior)
3. CloseAsync was not called at all --> call msquic Shutdown with the default CloseErrorCode, wait for SHUTDOWN_COMPLETE, and then release the resources as usual (same as now but wrongly documented)

What you think?

Triage: this should be fixed in 8.0, this a bug.

[bentoi]

Sounds good to me!