sentry-javascript: Undefined hub.startSession on v6 upgrade

Review the documentation: https://docs.sentry.io/
Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
Use the latest release: https://github.com/getsentry/sentry-javascript/releases
Provide a link to the affected event from your Sentry account

Package + Version

other: @sentry/react

Version:

6.0.4

Description

I’m getting an error when bumping @sentry/react to v6.0.4:

Uncaught TypeError: hub.startSession is not a function
    at startSessionTracking (sdk.ts:221)
    at init (sdk.ts:106)
    at Module.init (sdk.ts:18)
    at Module.<anonymous> (index.tsx:22)
    at Module../src/index.tsx (index.tsx:64)
    at __webpack_require__ (bootstrap:856)
    at fn (bootstrap:150)
    at Object.1 (wdyr.js:11)
    at __webpack_require__ (bootstrap:856)
    at checkDeferredModules (bootstrap:45)
    at Array.webpackJsonpCallback [as push] (bootstrap:32)
    at main.chunk.js:1

Debugging this line, hub indeed does not seem to have a startSession function on its prototype.

Disabling autoSessionTracking fixes the issue, but is this expected?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 26 (8 by maintainers)

Most upvoted comments

Same here I get this error hub.captureSession is not a function after updating to v6.2.0. I am using a single Sentry installation on a react project and I don’t have FileStack.

edit: I can provide a sentry issue link, I hope this can help https://sentry.io/organizations/mineko-gmbh/issues/2225137133/

fredicious on Feb 18, 2021

Yes, that would do it, if the first one initialized was < 5.27.0

Hm ok. So running two sentry instances is not supported? Where does it conflict?

We rely on a global Hub object, which doesn’t get overwritten by the second Sentry.init() call. If that call is from 6.x, it tries to start a session, and that’s where you run into the problem you’re having. What we tell people to do is to create a second hub, rather than calling Sentry.init() again.

That said, we are rethinking the hub/client architecture in version 7, which is being worked on now, and we’ll keep this issue in mind as we do.

If this error truly brought your app down, then I apologize. I’m not sure how it would do that, though, and I’d be curious to hear how it did if so.

Yeah it did, but only for around a day.

So basically I’m working for a startup that does AI recommendations. And to lower the hurdle of integrating our recs into their site (which is like the biggest sale-blocker) we often integrate by letting them add a “content script” to their site which then adds recommendations to the page (or replaces them).

And we’re using sentry in the script to catch the edge cases where something is not working as expected.

Hmmm. I think I understand your setup, and it does better explain how there might be two Sentry instances, if your client is running Sentry themselves and then you try to run Sentry on top of that. But what I’m not clear about is how it would bring your app (or even your Sentry instance) down. The hub.startSession call is the last thing Sentry.init does, after everything else has already been set up. So, yes, the error would trigger with the version mismatch, but after that, everything should work normally. (I was able to send a test message from the console on https://houdinisportswear.com/sv-se, for example.)

In any case, because you’re now the third person with this same problem (albeit for different reasons each), I’ve put up a PR wrapping that specific call in a check for the existence of hub.startSession.

lobsterkatie on Feb 25, 2021

@danieltroger, yeah I’ve been battling the same thing as mentioned above and in https://github.com/getsentry/sentry-javascript/issues/3206.

The latest update from @lobsterkatie over there (thanks!):

having two conflicting Sentry instances (one with the user agent integration and one without) could be the root cause of the problem

I’m still waiting on a new release of my presumably problematic dependency (filestack-js), so I haven’t confirmed the @sentry/minimal version bump actually fixes this issue (but it’s sounding like it will).

I’ll let @lobsterkatie shed some more light on your scenario, though, as it sounds like you don’t have control over the version of the other Sentry instance.

namoscato on Mar 3, 2021

Unfortunately, Proxy is not supported in IE, thus we’d need to pull a whole polyfill for that. And it’s actually one of the solutions to the ad-blockers issue that we recommend - https://docs.sentry.io/platforms/javascript/troubleshooting/#dealing-with-ad-blockers

kamilogorek on Feb 19, 2021

Since the work is now in the filestack end of things, I’m going to close this. Please let me know if problems persist after they upgrade.

lobsterkatie on Feb 16, 2021

@lobsterkatie, that’s a good thought but not the case.

I spent some more time with this and isolated the issue to a conflicting filestack-js dependency. Here’s a simple sandbox that illustrates the issue. I haven’t looked into their implementation yet and am happy to reach out to them about it, but do any of you have any thoughts / recommendations?

It’s worth noting this issue seems to prevent a bunch of context from making its way to Sentry as well.

namoscato on Feb 4, 2021