fix(core): Decrease number of Sentry stack frames for messages from captureConsoleIntegration

[Lms24]

Change

This PR creates a synthetic exception already within the captureConsole handler, so that we minimize the number of Sentry stack frames in the stack trace. It also adjusts the Client::captureMessage method to favor an already provided syntheticException over the one it would create.

Context

If users set attachStackTrace: true in their SDK config, our SDK will add stack frames from an internally created error ("synthetic exception") to events that don't have an original stack trace (e.g. captureMessage calls or captureException('string error')). When using captureConsoleIntegration instrumentation to automatically capture messages from console logs, the synthetic exception would be created so deeply in the call stack that the actual console.* call frame would no longer be in the stack trace due to Node limiting the number of frames to 10 by default.

Users can increase the limit, for example by setting Error.stackTraceLimit = N, but ideally they don't have to.

Alternatives considered

We discussed setting Error.stackTraceLimit to something like 50 (the max number of frames we parse) within the SDK but decided against it due to memory and payload concerns. We can revisit if stack frame limit problems get reported again.

closes #18094

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.64 kB	+0.03%	+5 B 🔺
@sentry/browser - with treeshaking flags	23.13 kB	+0.04%	+7 B 🔺
@sentry/browser (incl. Tracing)	41.27 kB	+0.02%	+7 B 🔺
@sentry/browser (incl. Tracing, Profiling)	45.55 kB	+0.02%	+5 B 🔺
@sentry/browser (incl. Tracing, Replay)	79.51 kB	+0.01%	+5 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.2 kB	+0.01%	+5 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	84.21 kB	+0.01%	+5 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	96.38 kB	+0.01%	+1 B 🔺
@sentry/browser (incl. Feedback)	41.32 kB	+0.02%	+6 B 🔺
@sentry/browser (incl. sendFeedback)	29.31 kB	+0.02%	+4 B 🔺
@sentry/browser (incl. FeedbackAsync)	34.24 kB	+0.02%	+5 B 🔺
@sentry/react	26.33 kB	+0.03%	+6 B 🔺
@sentry/react (incl. Tracing)	43.25 kB	+0.02%	+8 B 🔺
@sentry/vue	29.13 kB	+0.02%	+5 B 🔺
@sentry/vue (incl. Tracing)	43.06 kB	+0.02%	+7 B 🔺
@sentry/svelte	24.65 kB	+0.03%	+5 B 🔺
CDN Bundle	26.9 kB	+0.03%	+6 B 🔺
CDN Bundle (incl. Tracing)	41.8 kB	+0.02%	+6 B 🔺
CDN Bundle (incl. Tracing, Replay)	78.07 kB	+0.01%	+4 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	83.56 kB	+0.01%	+5 B 🔺
CDN Bundle - uncompressed	78.92 kB	+0.03%	+23 B 🔺
CDN Bundle (incl. Tracing) - uncompressed	124.03 kB	+0.02%	+23 B 🔺
CDN Bundle (incl. Tracing, Replay) - uncompressed	239.22 kB	+0.01%	+23 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	251.99 kB	+0.01%	+23 B 🔺
@sentry/nextjs (client)	45.37 kB	+0.02%	+7 B 🔺
@sentry/sveltekit (client)	41.68 kB	+0.02%	+6 B 🔺
@sentry/node-core	50.81 kB	+0.01%	+4 B 🔺
@sentry/node	157.89 kB	+0.01%	+4 B 🔺
@sentry/node - without tracing	92.7 kB	+0.01%	+9 B 🔺
@sentry/aws-serverless	106.43 kB	+0.01%	+5 B 🔺

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	9,281	-	8,837	+5%
GET With Sentry	1,326	14%	1,275	+4%
GET With Sentry (error only)	6,256	67%	5,923	+6%
POST Baseline	1,210	-	1,153	+5%
POST With Sentry	500	41%	476	+5%
POST With Sentry (error only)	1,044	86%	1,018	+3%
MYSQL Baseline	3,298	-	3,212	+3%
MYSQL With Sentry	458	14%	366	+25%
MYSQL With Sentry (error only)	2,684	81%	2,570	+4%

View base workflow run

[chargome]

Looks good!