How to deal with exceptions in underlying stream?

[lostmsu]

I use JsonRpc over custom network-based DataChannelStream, wrapped in BrotliStream for compression. I use the simplified JsonRpc.Attach<T>(stream) to obtain the wrapper for the remote service.

The problem is when connection drops (I'm not quite sure for the reason, but it is not important right now), the whole app crashes due to (as far as I understand it) unobserved exception in a worker thread. Here's the stack trace:

System.AggregateException: One or more errors occurred. (Data channel is closed)
---> System.IO.IOException: Data channel is closed
DataChannelStream.Write(ReadOnlySpan1 buffer) in DataChannelStream.cs:line 248
--- End of inner exception stack trace ---
at DataChannelStream.Write(ReadOnlySpan buffer) in DataChannelStream.cs:line 250
at System.IO.Compression.BrotliStream.WriteCore(ReadOnlySpan buffer, Boolean isFinalBlock)
at System.IO.Compression.BrotliStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at Nerdbank.Streams.FullDuplexStream.CombinedStream.Dispose(Boolean disposing)
at System.IO.Stream.Close()
at StreamJsonRpc.PipeMessageHandler.<>c.<.ctor>b__4_0(Exception ex, Object state)
at System.IO.Pipelines.PipeCompletionCallbacks.Execute(PipeCompletionCallback callback, List& exceptions)
--- End of inner exception stack trace ---
at System.IO.Pipelines.PipeCompletionCallbacks.Execute()
at System.IO.Pipelines.Pipe.<>c.<.cctor>b__100_2(Object state)
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()

Is creating JsonRpc instance explicitly and awaiting its Completion my only option here?

P.S. Here FullDuplexStream is used because BrotliStream is not full-duplex (e.g. I have to create one for receiving + decompression and another for compression + sending)
P.P.S. StreamJsonRpc v2.19.27

[AArnott]

Unobserved faulted tasks don't crash the process. Only .NET Framework 4.0 did that. 4.5+ removed that behavior. So awaiting Completion won't solve anything here.

Throwing exceptions that are not caught, all the way down to the thread start method on the other hand... that will crash the process. And that appears to be what's happening here, as you have surmised. Dispose methods are not supposed to throw exceptions1 2.

That all said, StreamJsonRpc could make a change to swallow these exceptions, I suppose.

[lostmsu]

Dispose methods are not supposed to throw exceptions

Funny you say that, there just was yet another discussion on the topic on HN.

https://news.ycombinator.com/item?id=41479283

I suppose considering the stack trace this is a bug in BrotliStream.Dispose.

Alternatively, could that be that PipeMessageHandler should do Flush before trying to Dispose. While you are correct Dispose is not supposed to throw (although it can't just eat errors either), but the same is not said about Stream.Close which PipeMessageHandler appears to be calling.

[lostmsu]

Also, for swallowing, maybe have an overload that takes some kind of exception observer?

[AArnott]

The crashes were from calling Dispose -- not Close. You can see the fixes made here: #1085

While I wouldn't object to exposing an API that could observe these now-swallowed exceptions, I don't know where I'd expose it. They can come in too late to be included in the JsonRpc.Completion property.

As for calling Flush first, all the Stream's I've come across include a final flush as part of Dispose when there are unflushed buffers. And in these two particular cases for PipeMessageHandler, we're calling Dispose after either being canceled or when the stream itself tells us the connection has closed. In either case, flushing any remaining bytes to be written seems pointless.