Skip to content

Manually instantiated Hub with provided client instance, shouldn't require additional bindClient call to setup integrations #2541

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

Closed
5 of 9 tasks
NicHaley opened this issue Apr 15, 2020 · 6 comments · Fixed by #2665

Comments

@NicHaley
Copy link

Package + Version

  • @sentry/browser
  • @sentry/node
  • raven-js
  • raven-node (raven for node)
  • other:

Version:

5.15.4

Description

As per the Advance Usage docs, I am trying to manage several instances of Sentry. I am developing a widget and would like to use Sentry without it conflicting with the host page.

Creating new instances BrowserClient and Hub classes seems to be a great way to do that, but I can't get it to work with my integrations. I found a similar issue #2329, however it was resolved by using hub.run(...). This does not work for me.

There was another thread #1764 as well, but the provided solution involves setting the new hub to the current global hub with getCurrentHub().bindClient(client);. This works, but it seems to defeat the point of what I'm trying to accomplish since I don't want to modify any globals that might interfere with the host page.

My code looks like this:

const { Hub, BrowserClient, defaultIntegrations } = Sentry;

const client = new BrowserClient({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  integrations: defaultIntegrations
});

const hub = new Hub(client);

// ...Later

hub.run((currentHub) => {
  currentHub.captureException(error);
});
@NicHaley
Copy link
Author

NicHaley commented Apr 20, 2020

As an aside, I also tried triggering an exception directly from the Client based on the Advanced Usage docs:

client.captureException(new Error('example'));

This also fails to work with integrations passed to the Client.

@mcaballeropinto
Copy link

@NicHaley By reading the source code, I found that you need to explicitly call setupIntegrations on the Client object for the integrations to be added to the client. Here is the source code:

public setupIntegrations(): void {

Alternatively you can call bindClient instead of passing the client through the Hub constructor. That function calls setupIntegrations internally. The source code:

client.setupIntegrations();

I also found that the GlobalHandlers integration calls getCurrentHub to get the instance of the hub to interact with. This means that it will only work with a global hub. See an example here:

const currentHub = getCurrentHub();

In general, I think the advance experience of creating your own hub instance it not completely polished and you are pretty much on your own in terms of integrations unfortunately.

@kamilogorek
Copy link
Contributor

Thanks for the feedback @mcaballeropinto. @NicHaley the comments above are correct. You need to manually bind the client to the new hub as well hub.bindClient(client). This looks like an oversight on our end, as it's a very rarely used feature.
I'll rename this issue to more descriptive one and mark it as a bug.

@kamilogorek kamilogorek changed the title Integrations don't work with Hub run Manually instantiated Hub with provided client instance, shouldn't require additional bindClient call to setup integrations May 20, 2020
@NicHaley
Copy link
Author

NicHaley commented May 20, 2020

Thanks @mcaballeropinto and @kamilogorek. The above makes sense. I am using the Client directly, and leveraging setupIntegrations should give me most of what I need for the time being.

@mcaballeropinto
Copy link

Thanks @kamilogorek! I see you want to use this issue to fix having to call bindClient explicitly. What about the issue of default integrations not working on custom Hubs, as expressed at the end of my comment: #2541 (comment)?

I also found that the GlobalHandlers integration calls getCurrentHub to get the instance of the hub to interact with. This means that it will only work with a global hub. See an example here:

Is this something you will consider looking at?

@NicHaley
Copy link
Author

We are experiencing a follow-up issue. It seems distinct from this one, so logged it as a new bug: #2622

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants