bugsnag / bugsnag-dotnet

.NET notifier for BugSnag. Error monitoring and error reporting for .NET.
https://docs.bugsnag.com/platforms/dotnet/
MIT License
60 stars 29 forks source link

Graceful Shutdown #165

Open molynerd opened 1 year ago

molynerd commented 1 year ago

Description

It doesn't seem like there's a way to gracefully terminate and make sure that all notified events make it to the bugsnag server. When an application runs in an ephemeral environment, I typically capture SIGTERM/SIGINT events as indicators to terminate the application, and before the application unloads, I "shutdown" all external connections.

Describe the solution you'd like A Shutdown() method on the bugsnag client or configuration object would be helpful such that I can register a cancellation token event. Contrived example:

// some boilerplate code that hooks into ProcessExit
var cts = new CancellationTokenSource();
AppDomain.CurrentDomain.ProcessExit += (_, _) => { cts.Cancel() }
return cts.Token;

// configuration of the bugsnag client the application will use
var config = new Bugsnag.Configuration("foo");
var client = new Bugsnag.Client(config);
cts.Token.Register(() => client.Shutdown());

Describe alternatives you've considered One could just hook into ProcessExit and attempt to force the application to stay open as long as .NET would allow, but this doesn't guarantee that all of the notify events make it to bugnsag.

Additional context It's possible that Bugsnag.Client.Notify is a blocking operation, but in a multithreaded application, there is no guarantee that the ProcessExit will wait for all threads to stop. This is where a cancellation token is important.

Imagine a scenario where an exception is thrown on app startup. With no graceful termination, the application dies, the bug report registered with the bugsnag client never reaches the bugsnag server, and the error is essentially lost. In a highly scaled/ephemeral environment, it could be impossible to debug without the report details.

clr182 commented 1 year ago

Hi @molynerd Agreed, it seems like a sensible idea to implement a more graceful shutdown method and we are discussing approaches internally. Feel free to open a PR if you have time and have something in mind, and we will review it when priorities allow.