If `attachStacktrace` is enabled, `captureMessage` should include the stack trace in the `threads` interface

[marandaneto]

Problem Statement

When attachStacktrace is enabled, captureMessage calls don't set the stack trace.
Related issue getsentry/sentry-react-native#2131

Code:

sentry-javascript/packages/browser/src/eventbuilder.ts

Lines 275 to 282 in 28c464d

	if (attachStacktrace && syntheticException) {
	const frames = parseStackFrames(stackParser, syntheticException);
	if (frames.length) {
	event.exception = {
	values: [{ value: input, stacktrace: { frames } }],
	};
	}
	}

Since syntheticException is null, it does not set the stack trace.
Ideally, there will be an else branch that checks the attachStacktrace flag and sets the stack trace in the threads interface.

Solution Brainstorm

When attachStacktrace is enabled, captureMessage contains the stack trace in the threads section since there's no exception to attach the stack trace to.

Mobile SDKs already do it.

[INNOVATIVEGAMER]

Ok, I get the context here. Also I have gone through https://develop.sentry.dev/sdk/event-payloads/threads/.
But How do you test the expected behaviour?

I have used sentry as SDK previously in organization. But do not have experience in contributing in it. Can somebody please help me here ?

[INNOVATIVEGAMER]

@AbhiPrasad Can you please help here ? It will be very helpful.

[AbhiPrasad]

@marandaneto do you mind clarifying the details here? hub.captureMessage should be creating a synthetic exception for us always here, and if that does not exist we don't have anything to parse frames from.

Is it that we should always be using threads?

[marandaneto]

@marandaneto do you mind clarifying the details here? hub.captureMessage should be creating a synthetic exception for us always here, and if that does not exist we don't have anything to parse frames from.

Is it that we should always be using threads?

Yes, exactly, we just need a synthetic exception in order to get access to its stack traces, but it's not an exception so it should not be set as an exception.
Setting it as part of threads, gives us insights into where the captureMessage was called.

[AbhiPrasad]

@krystofwoldrich feel free to revive this PR whenever you get the chance. We can get it in for v8!