fix(node): Avoid creating breadcrumbs for suppressed requests

[mydea]

It was noticed that we were creating breadcrumbs for sentry-internal requests, which is not desired. This was introduced by us moving breadcrumb generation out of the base http/fetch instrumentation into our own, where we did not look at suppressTracing. Now, when tracing is suppressed, no fetch/http breadcrumbs will be created.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	23.96 kB	-	-
@sentry/browser - with treeshaking flags	23.62 kB	-	-
@sentry/browser (incl. Tracing)	38.21 kB	-	-
@sentry/browser (incl. Tracing, Replay)	76.32 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.35 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	81.09 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	93.18 kB	-	-
@sentry/browser (incl. Feedback)	40.76 kB	-	-
@sentry/browser (incl. sendFeedback)	28.7 kB	-	-
@sentry/browser (incl. FeedbackAsync)	33.58 kB	-	-
@sentry/react	25.77 kB	-	-
@sentry/react (incl. Tracing)	40.21 kB	-	-
@sentry/vue	28.34 kB	-	-
@sentry/vue (incl. Tracing)	40 kB	-	-
@sentry/svelte	23.99 kB	-	-
CDN Bundle	25.17 kB	-	-
CDN Bundle (incl. Tracing)	38.23 kB	-	-
CDN Bundle (incl. Tracing, Replay)	74.11 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	79.54 kB	-	-
CDN Bundle - uncompressed	73.44 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	113.15 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	227.11 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	239.93 kB	-	-
@sentry/nextjs (client)	41.86 kB	-	-
@sentry/sveltekit (client)	38.68 kB	-	-
@sentry/node	158.02 kB	+0.02%	+23 B 🔺
@sentry/node - without tracing	97.92 kB	+0.03%	+28 B 🔺
@sentry/aws-serverless	123.27 kB	+0.02%	+24 B 🔺

View base workflow run

[Lms24]

Sorry for the naive question but I don't see the immediate connection between breadcrumb generation and tracing being suppressed. As in, breadcrumbs are not part of a trace but "their own" thing and they happen to get attached to transaction payloads (as well as errors). or IOW: Why should suppressTracing control breadcrumb creation behaviour? Fwiw, we expose beforeAddBreadcrumb to filter out breadcrumbs users don't want.

Btw, agree that we shouldn't create breadcrumbs for Sentry requests :)

[mydea]

Yeah, this is a valid question :) This basically matches the behavior we originally had, and means that we do not need some heuristic to detect our own API requests anymore, we can just rely on this. It also means that e.g. other analytics/otel requests that users may wrap with suppressTracing will also not get breadcrumbs, which also seems OK to me 🤔 Overall, I think it is generally OK/desireable to not have these requests as breadcrumbs...?

Alternatively, we need to re-add some way to identify our own API requests and only filter out these, which is also doable of course :)

[Lms24]

Sorry for the late reply!

I still think it's not "clean" to also include breadcrumbs here but it's pragmatic and what we need as well as what probably the majority of users want. So it's probably one of these "let's roll with it until we or other people complain" changes :D

---

Some thoughts on alternatives (for when we reach the complaint point):

1. Make breadcrumb collection toggleable via an option
2. Create a more generalized Sentry.suppress (naming tbd) API where you can granularly toggle individual telemetry signals.