Repository navigation
Manually instantiated Hub with provided client instance, shouldn't require additional bindClient call to setup integrations #2541
Description
- 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: https://sentry.io/organizations/ada/issues/1612951359/?environment=development&project=1410309&query=is%3Aunresolved
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);
});
Activity
NicHaley commentedon Apr 20, 2020
As an aside, I also tried triggering an exception directly from the
Clientbased on the Advanced Usage docs:client.captureException(new Error('example'));This also fails to work with integrations passed to the Client.
mcaballeropinto commentedon May 19, 2020
@NicHaley By reading the source code, I found that you need to explicitly call
setupIntegrationson theClientobject for the integrations to be added to the client. Here is the source code:sentry-javascript/packages/core/src/baseclient.ts
Line 196 in 2efbc98
Alternatively you can call
bindClientinstead of passing the client through theHubconstructor. That function callssetupIntegrationsinternally. The source code:sentry-javascript/packages/hub/src/hub.ts
Line 91 in 2efbc98
I also found that the GlobalHandlers integration calls
getCurrentHubto get the instance of the hub to interact with. This means that it will only work with a global hub. See an example here:sentry-javascript/packages/browser/src/integrations/globalhandlers.ts
Line 142 in 2efbc98
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 commentedon May 20, 2020
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.
[-]Integrations don't work with Hub run[/-][+]Manually instantiated Hub with provided client instance, shouldn't require additional bindClient call to setup integrations[/+]NicHaley commentedon May 20, 2020
Thanks @mcaballeropinto and @kamilogorek. The above makes sense. I am using the
Clientdirectly, and leveragingsetupIntegrationsshould give me most of what I need for the time being.mcaballeropinto commentedon May 26, 2020
Thanks @kamilogorek! I see you want to use this issue to fix having to call
bindClientexplicitly. What about the issue of default integrations not working on custom Hubs, as expressed at the end of my comment: #2541 (comment)?Is this something you will consider looking at?
NicHaley commentedon May 27, 2020
We are experiencing a follow-up issue. It seems distinct from this one, so logged it as a new bug: #2622