-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Force Sentry to wait for every captureException call #15058
Comments
Hello @cideM, I tried adding your Could you please provide a sample reproduction repo? Also, check out https://docs.sentry.io/platforms/javascript/configuration/transports/#custom-transport, we have a helper called Although, if your framework exits with |
Our transport creates and resolves promises (async code) as sending the event is I/O, and so therefore there never will be a strong guarantee that all events will get flushed. I recommend re-architecting the app so that a call to |
Problem Statement
I have been working with the Go SDK for a while now and it's very pleasant to use and even includes a Sync transport.
I am now working in a Javascript project that uses a framework which unfortunately calls
process.exit
quite often. As a result, Sentry errors never make it to our dashboard, since Sentry doesn't have time to flush the buffer. I thought I could just set some option and force Sentry to wait for every singlecaptureException
callSolution Brainstorm
One potential workaround would be to overwrite
process.exit
and callSentry.close()
in there.I thought that I could also provide a sync transport (there appears to be none) so I tried something very simple:
Later in this file I am doing the following to trigger the custom transport:
I'd expect to see something in my console that indicates that
send
was called, but I don't. Is there some buffering going on before my custom transport is called?It seems that there is currently no way to force Sentry to wait until every single
captureException
call has finished.The text was updated successfully, but these errors were encountered: