getsentry
If `attachStacktrace` is enabled, `captureMessage` should include the stack trace in the `threads` interface
Problem Statement
When attachStacktrace is enabled, captureMessage calls don't set the stack trace.
Related issue https://github.com/getsentry/sentry-react-native/issues/2131
Code: https://github.com/getsentry/sentry-javascript/blob/28c464d1977f4c5e9c91764462da84c07d6ecad3/packages/browser/src/eventbuilder.ts#L275-L282
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.
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 ?
@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 do you mind clarifying the details here?
hub.captureMessageshould 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.
@krystofwoldrich feel free to revive this PR whenever you get the chance. We can get it in for v8!