Asynchronous Loading and Capturing Errors

[karolisdzeja]

I want to be able to load raven.js asynchronously, but still be able to capture errors while the script is loading. (Something like how Google Analytics handles events by storing them in a variable until the library loads).

Here's what I have so far: https://gist.github.com/karolisdzeja/8010574

But doing it that way loses some of the information and detail that Raven usually provides. Is there a way to store the full error information similarly to this?

[PatrickJS]

+1

[nathmisaki]

+1

[Sija]

+1

[sodevious]

+1

[benvinegar]

Everyone who's commented on this – what's wrong with the solution by @karolisdzeja?

Ultimately, I'm not sure how we can add a feature to the Raven.js source that is supposed to work when Raven.js source isn't on the page. I think this will always ultimately be a custom solution; at best we could add a "how to" to our docs.

[jwheare]

@benvinegar the solution looks fine, but it would be better if this was officially supported and documented. I'm happier just having to trust the Sentry team over evaluating a random gist.

[jwheare]

Actually, a much better solution would be something like Twitter's JS SDK code: https://dev.twitter.com/web/javascript/loading

Setup a function queue on page load that then gets consumed when the external js has been loaded, replacing the proxy object. And make sure all API calls go through something like a .ready() call to the proxy.

This ensures that any call can be queued up before the js has loaded rather than just captureMessage, without having to proxy every function individually.

I'd love to be able to just load raven.js asynchronously/deferred and not have to worry.

[jwheare]

Other problems with the gist: it clobbers window.onerror and introduces a few uncontained global variables.

[jwheare]

It also doesn't make use of the full-featured traceKitWindowOnError function that raven.js uses when it loads.

[oroce]

I slightly redid the gist above: https://gist.github.com/oroce/ec3786ba7eff59963842220c3ffc56b4

There's no leaking variable. I kept the window.onerror handler, but feel free to use window.addEventListener('error', fn).

The biggest help at point be having traceKitWindowOnError as an exported function from Raven. Since that's the function which gets called when an error happens: https://github.com/getsentry/raven-js/blob/master/dist/raven.js#L2074

I know we wouldn't have that very proper stacktrace but we would have something better than what we have now.

[benvinegar]

There's other downsides with doing this:

• By relying on window.onerror to catch errors before Raven is loaded, stacktraces are not available for every browser
  • besides not having a stack trace, this will affect grouping negatively
  • this is why install() does try/catch instrumentation
• Synthetic traces will not work (they will all appear as originating from this code)
• No breadcrumb collection

So, you're trading potentially better performance for lower quality error reports. If async execution is important, I'd sooner recommend you bundle Raven with your own code so that it is served together.

[oroce]

@benvinegar you are completely right. In applications which aren't public (aka google won't reach the pages) the classic (blocking) raven way is completely fine but as soon as you have a public facing site where the google page insight points do matter, we need to optimize how we load third party code (this is the price we are willing to pay in favour of ux, speed and better search result position).

Moreover bundling raven into our bundle is a solution, but as soon as you get into optimizing your frontend code with above the fold optimizations, like splitting your bundle into multiple ones using tools like factor-bundle or you include multiple bundles to gain more speed, the above solution can be a better one imo, but I'm open for suggestions.

[vinhlh]

They all have trade-offs, so it would be great if we can document all available strategies, so depend on per specific web application, we will apply different strategies.
With async strategy, we should load the script after onload event, instead of loading async only, to prevent blocking onload event, rendering.

/**
 * Setup Js error lazy tracking
 * - Pros: doesn't block rendering, onload event
 * - Cons: lower quality error reports for lazy errors
 *
 * @author vinhlh
 *
 * @param  {object} window
 * @param  {object} labJs
 * @param  {string} ravenCdn
 * @param  {string} sentryDsn
 */
(function(window, labJs, ravenCdn, sentryDsn) {
  var errors = [];
  var oldOnError = window.onerror;

  window.onerror = function() {
    errors.push(arguments);
    oldOnError && oldOnError.apply(this, arguments);
  };
  window.addEventListener('load', function() {
    labJs
      .script(ravenCdn)
      .wait(function() {
        window.onerror = oldOnError;
        Raven.config(sentryDsn).install();
        errors.forEach(function(args) {
          window.onerror.apply(this, args);
        });
      });
  });
})(window, $LAB, 'raven-js-3.8.1/dist/raven.js', 'https://xxx@domain.com/9');

[benvinegar]

I think we'll probably just document an async snippet, like the ones provided above, but mention that it comes with tradeoffs.

Just one other comment. Those tradeoffs might seem acceptable, but I deal with a lot of support tickets from users about low-fidelity errors they are experiencing that are (incorrectly) believed to derive from Raven.js. My fear is that if I encourage people to use the async approach, I'll have more and more people asking me "why is there no stack trace" and other complaints when it's because this approach is lower fidelity. I'm willing to accept that, but it's a tough pill to swallow. 😓