We’re loading the Sentry Browser SDK from the CDN and calling Sentry.init() to configure it. We would like for errors to not be logged until we call Sentry.init(). Ideally errors caught before Sentry.init() would be queued so that they could be run through our custom beforeSend filtering.
Are errors supposed to be logged before Sentry.init() is called? Is there any way to stop it?
We’re calling Sentry.init() a little late because we want to filter out errors from old browsers. Our site has a rather strict set of supported browsers. We have logic client-side to detect whether a browser is supported, and we’d like to call that from beforeSend but the logic is in a file that’s loaded async so we need to wait for that file to load. Hence it’d be ideal of errors caught before Sentry.init() were queued and would be run through our custom beforeSend filter when it’s ready.
So if you are using the bundle directly from the CDN (not the loader) it should not “catch” unhandled errors before you call Sentry.init().
The loader works different in way that it’s a slim wrapper over global error handlers and in case of an error we inject the full bundle into your page and send it to Sentry.
You could copy the code of the loader to adjust it to your needs
You’re right about Sentry not catching errors before Sentry.init(). I was mistaken.
The file you linked to has a queue in it. It appears to be doing what we want: queue errors until the SDK is fully loaded and replay them. Is that right? That’s not the behavior I was seeing earlier in my initial investigations. I’ll dig deeper to see what’s going on.
You say that we could copy and modify that script to have our own loader. But then we’d be in charge of keeping it up to date. Is that the only solution?
We do not often update this script and your use-case is very specific, changing this in general means more code in the loader, which means a larger loader for everyone. Probably most people probably don’t need this functionality.