Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graceful Shutdown #165

Open
molynerd opened this issue Jul 25, 2023 · 1 comment
Open

Graceful Shutdown #165

molynerd opened this issue Jul 25, 2023 · 1 comment
Labels
feature request Request for a new feature needs discussion Requires internal analysis/discussion

Comments

@molynerd
Copy link

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 clr182 added needs discussion Requires internal analysis/discussion feature request Request for a new feature labels Jul 26, 2023
@clr182
Copy link

clr182 commented Jul 26, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Request for a new feature needs discussion Requires internal analysis/discussion
Projects
None yet
Development

No branches or pull requests

2 participants