SIPTransport.SIPTransportRequestReceived async event result not checked

[mikhail-barg]

Hi,

as you may see at https://github.com/sipsorcery-org/sipsorcery/blob/afb3cd3b7f0f05df109aaea4faa9b23650902803/src/core/SIP/SIPTransport.cs#L1080 a task returned from SIPTransportRequestReceived() is neither awaited, nor returned or checked in any other way, so in case exception happens in the handler, it turns into TaskScheduler UnobservedTaskException which is quite bad.

[sipsorcery]

The idea is that SIP request and response events are triggered for consuming application to do as they see fit. The events are meant to be fire and forget so that the SIPTransport does not get blocked by the application taking it's time processing an event.

it turns into TaskScheduler UnobservedTaskException which is quite bad.

Is it though?

https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.taskscheduler.unobservedtaskexception?view=net-6.0

I mean it's not great when an exception is thrown but in this case I'd say that's better than potentially blocking the SIPTransport thread on every request and/or response.

[mikhail-barg]

Is it though?

Well, I do know that for a long time unobserved task exceptions are not causing runtime to terminate the app. Still, if you don't catch those via TaskScheduler.UnobservedTaskException, you are risking to get all kinds of silent failures — thinking that your app is OK, while it's full of exceptions.

I mean it's not great when an exception is thrown but in this case I'd say that's better than potentially blocking the SIPTransport thread on every request and/or response.

Yeah, I do understand your concern, but could there be some intermediate solution? Like linking the fire-and-forget tasks to some special task chain or some observer for such tasks?

Right now there's no simple way to know what to do in case of such task finishing with an exception. For example I found this place while investigating a NRE in a SIPTransportRequestReceived handler, and it's not quite clear to me, is it OK to continue running an app after the exception, or the whole sip stack is now in a corrupted state.

[sipsorcery]

is it OK to continue running an app after the exception, or the whole sip stack is now in a corrupted state.

Perhaps it depends on whether it's a client or server app.

The sipsorcery code was originally written for a server application and the absolute worse scenario was for it to crash or block on a single request.

For client applications that may not be the case. The client care about the current call and would like to block to catch any exceptions.

I don't have a good answer of how to deal with exceptions on the events fired by the SIPTransport and am open to any suggestions. The caveat is the SIPTransport thread processing the incoming messages can't block as that would be catastrophic for server applications.