TypeError: t.startSession is not a function

[henricook]

I use renovate and upgraded to @sentry/browser 6.0.1 as an everyday task.

The release caused my entire React app's page load to fail - a blank white page with a TypeError t.startSession is not a function error in the console.

Please delete the release or at the very least do something to mark it as dangerous. I happen to be lucky enough to have a staging environment also using Sentry, but it was a worryingly close call to production.

After testing, this issue is NOT fixed in 6.0.2

[lobsterkatie]

@henricook - did you upgrade all of your Sentry packages to 6.x, or just @sentry/browser?

[henricook]

Renovate automatically upgraded: Browser, core, types, utils, hub, minimal

Together

[lobsterkatie]

Yes - that's how it's supposed to work. 🙂 But an outdated version of @sentry/hub (without startSession) would be the most straightforward explanation here. startSession is only called twice in any of our packages, as a method on Hub, and as you can see, the Hub class does indeed have a startSession method.

I'm unable to replicate this in my react test app. Are you able to create a minimal repro case?

[henricook]

Thanks, apologies for the inflammatory title. I'll give it a go if you don't think it's a universal issue, more tomorrow.

[henricook]

Embarrassingly this is due to me also <script src=ing raven-4.0.2.min.js - a very old version of the self hosted SDK.

My application serves people with restrictive whitelists, I use a self hosted sentry AND sentry.io in the hope that one of them will be unblocked for the user. I'll remove the Raven import and check that i can use both sentry instances with sentry/browser now - either way, I think this problem is mine!

If anyone has a ready example of using two sentry instances in one React app I'd greatly appreciate it

[henricook]

@lobsterkatie This looks ok? https://codesandbox.io/s/l7qrkjn7nm I'll give this a try unless anyone shouts there's a better way (thanks for your attention)

[lobsterkatie]

@henricook - yup, that looks fine, but be aware that you may run into some edge-casey weird behavior with the two hubs interacting/interfering with each other in the spots where they depend on global state. If I understand what you said correctly, you're wanting to make it so that all the errors you send to our servers also get sent to your server? Is that correct? Or is there more to it than that?

[henricook]

Thanks @lobsterkatie - each of my environments may have:

• my self hosted sentry only
  Or
• sentry.io only
  Or
• both

[lobsterkatie]

But the only difference between the two Sentry instances is the destination, right?

If so, you can actually just create one Sentry instance and use a beforeSend like this:

Sentry.init(
    dsn: "one of the two dsns",
    beforeSend: (event, hint) => {
        try {
          const client = new Sentry.BrowserClient({ dsn: "the other dsn" });
          client.captureEvent(event);
        } catch (_) {}
      return event;
    }
  )