Open molynerd opened 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.
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: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.