Database integrations are auto-loaded from @sentry/tracing when testing frontend projects

[Lms24]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which package are you using?

@sentry/angular

SDK Version

7.2.0

Framework Version

No response

Link to Sentry event

No response

Steps to Reproduce

No exact reproduction yet. This behaviour is noticed by Jest because it detects one of our DB integrations (Mongoose). However, impact is unclear: Does the behaviour break test suite execution or is it just showing a warning/info message?

Expected Result

When a Frontend JS SDK (i.e. @sentry/browser and derivatives) is used in conjunction with @sentry/tracing, _autoloadDatabaseIntegrations should not be called and hence, database integrations should not be set up.

Actual Result

As recently brought to our attention, our Frontend SDKs (for sure the Angular SDK but probably most other frontend JS SDKs, too) are auto-discovering database integrations if @sentry/tracing is used (i.e. added to the project and imported)
when the projects' tests are executed in a node envirnoment (e.g. Jest tests).

In the linked case above, the project lives in a monorepo in which also a DB library we automatically instrument (Mongoose) is listed as a dependency. In this case, the integration would be loaded (because of auto-discovery) and cause a Jest error.

This happens because _autoloadDatabaseIntegrations is called when the tracing package is imported:

sentry-javascript/packages/tracing/src/hubextensions.ts

Lines 290 to 296 in cafd6cb

	export function addExtensionMethods(): void {
	_addTracingExtensions();
	// Detect and automatically load specified integrations.
	if (isNodeEnv()) {
	_autoloadDatabaseIntegrations();
	}

_autoloadDatabaseIntegrations is called because isNodeEnv evaluates to true in this case. The function evaluates to true because a) we are in a Node environment and b) the isBrowserBundle check evaluates to false:

sentry-javascript/packages/utils/src/node.ts

Lines 13 to 19 in f042723

	export function isNodeEnv(): boolean {
	// explicitly check for browser bundles as those can be optimized statically
	// by terser/rollup.
	return (
	!isBrowserBundle() &&
	Object.prototype.toString.call(typeof process !== 'undefined' ? process : 0) === '[object process]'
	);

sentry-javascript/packages/utils/src/env.ts

Lines 23 to 25 in 334b097

	export function isBrowserBundle(): boolean {
	return typeof __SENTRY_BROWSER_BUNDLE__ !== 'undefined' && !!__SENTRY_BROWSER_BUNDLE__;
	}

The reason is that we only set the __SENTRY_BROWSER_BUNDLE__ for the NPM bundles that we build but not for our NPM packages.

We have a couple of options how to proceed here:

• Set the __SENTRY_BROWSER_BUNDLE__ magic string also in the NPM package build configs (for Angular, we have to handle it differently because we don't use rollup there)
• Find another mechanism disable auto-loading in frontend JS SDKs. E.g. use an allowList of SDKs in which DB integrations can be auto-loaded (we could check the SDK metadata against this list)
• Refrain from addressing this problem for now because we're planning to deprecate and remove auto loading of DB integrations for performance reasons anyway in the near future.

[Lms24]

We discussed this at our team meeting and decided to hold off from developing a fix ourselves for a couple of reasons:

1. (most importantly) We're going to remove auto discovery of DB integrations in the next major version of our SDKs (v8)
2. Given point 1 and the number of preconditions such that the bug described above would occur, we don't have the capacity to work on a fix which would soon get removed anyway.
3. Fixing this properly doesn't appear to be trivial because of timing concerns with Sentry.init which might require other packages than sentry-tracing to have side-effects which we do not want.

That being said, if our community wants to see this fixed, please react to the issue with an upvote or a comment. In this case, we'd highly appreciate more information how this bug occurs and how it is breaking you. Furthermore, if you happen to have some time, we're always happy to review and accept PRs. Thanks!

(Backlogging this issue for now and putting it to the 8.0.0 milestone in which this bug will be fixed anyway).

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[dbartholomae]

What's the timeline for version 8? Will this be solved soonish?

[AbhiPrasad]

Fixed in the latest release of the SDK: https://github.com/getsentry/sentry-javascript/releases/tag/7.46.0