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.
An earlier cut of #101 had a bunch of hooks on events like
unhandledRejectionwhich 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
onExitevent, 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.