How to handle errors in the interfaces

[kjersti]

We use this library to do routing from a SQL queue to an MSMQ. We have experienced that the program stopped processing messages from the SQL queue, without any signal that we were able to detect.

After the fact we have been able to find some traces in logs, indicating that there had been connectivity issues with the SQL database.

After digging through the code, it seems like the default behaviour for endpoints, when the peek or receive circuit breaker triggers, is to stop the endpoint. But, it does not stop the application it's running in. In those cases, we have an application that appears to be running, but it has stopped peeking on the SQL queues. In those cases, we prefer to just kill the application, and let other mechanisms try to restart the application if possible.

Fortunately, there seems to be a way to hook into the interfaces critical error handling, by setting a callback function in the settings, like this

var sqlInterface = _routerConfig.AddInterface<SqlServerTransport>("SQL", t =>
{
   t.GetSettings().Set("onCriticalErrorAction", OnCriticalError()); // The signature of the callback is Func<ICriticalErrorContext, Task>
  // other settings 
});

First, is this an appropriate way to hook up the critical error callback, or is this actually in internal interface, where the settings key might change?

Maybe a small note in the documentation about this? Or maybe the option to hook into the critical error could be made available in the configuration?

[SzymonPobiega]

Hi

Thanks for pointing this out. The settings key is stable and won't change but there should be a public API to set the critical handler on top of it. I'll add this API in the next service release. In the meantime you can use the settings. It will continue to work after the public API is added.

[kjersti]

Thanks for getting back to me, this is fine.