You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An earlier cut of #101 had a bunch of hooks on events like unhandledRejection which attempted to gracefully shut down tracing before an exit. However, there are a few problems with this:
Boltzmann today doesn't do anything like this - if we were to handle those cases for honeycomb, we would need to handle them for non-honeycomb cases too, and doing so would be a major-version API change
At least some of the events handle async actions poorly - we would need to research this and figure out what's realistically possible.
Our current approach for #101 is to only listen for the onExit event, which should fire on a non-error exit. This should get us graceful shutdown in the event of a service roll. If the app hard crashes we may lose some trace data, but if that's the case we have bigger problems which will surface themselves through on-call incidents. This approach is acceptable for now, but following up on this behavior later - in both honeycomb and non-honeycomb cases - could be worthwhile.
The text was updated successfully, but these errors were encountered:
An earlier cut of #101 had a bunch of hooks on events like
unhandledRejection
which attempted to gracefully shut down tracing before an exit. However, there are a few problems with this:Our current approach for #101 is to only listen for the
onExit
event, which should fire on a non-error exit. This should get us graceful shutdown in the event of a service roll. If the app hard crashes we may lose some trace data, but if that's the case we have bigger problems which will surface themselves through on-call incidents. This approach is acceptable for now, but following up on this behavior later - in both honeycomb and non-honeycomb cases - could be worthwhile.The text was updated successfully, but these errors were encountered: