Identify how errors without a stack trace happen
For context: https://github.com/getsentry/sentry-javascript/discussions/5334
For this to be resolved, we should identify how errors without stack traces happen, and how to reproduce them.
- [ ] Investigate v8 source code to see when stack trace is attached
- [ ] Query sentry events to see JavaScript errors without stack trace
- [ ] Test
fetchscenarios to check stack trace - [ ] Analyze errors across browsers
As far as I can tell from speaking to @AbhiPrasad the issue is happening with Safari and Chrome; therefore, they are two different JavaScript runtimes.
I would research if they share the same message,
If so, I would focus on understanding if they rely on some Operation System-level components to do network in the case of fetch or something similar.
Otherwise, it will require investigating V8 and Safari Webkit to see where they are not giving enough insides.
Also, I will assume that such an issue comes from internal components so that is why not much information is given, which leads me to maybe research how the Consoles are now giving you nice linking between async operations, it may be the case that there is a way to add some metadata or that they are doing it at a layer that we cant control and not much we can do other than loop-in Browser vendors.
idea: (not mine) always throw a stack trace
Is there a way to filter out issues that have used captureMessage? I'm currently using !has:stack.filename.
An example of an issue without a stack trace is this one.
In this case, Sentry.captureMessage is used because fetchData has been called without checking
https://github.com/getsentry/sentry/blob/43d5623d0ee5f7652ce89bc51ea79d9620918d49/static/app/views/organizationGroupDetails/groupEventDetails/groupEventDetails.tsx#L125-L132
In other ways, the way the code is written allows for hidden up real issues.
Another example is this one
It seems to use captureMessage again.
https://github.com/getsentry/sentry/blob/a8c3c47c01a27f8c5282b2b534ad2fafa711990a/static/app/views/onboarding/createSampleEventButton.tsx#L142-L151
In other cases, the issue believes to have a stack trace but in reality an exception level error was logged (They could have used an error level instead). See this issue and the screenshots below.
It is possible that we're capturing a message in here as well.
Is there a way to filter out issues that have used
captureMessage?
I do think that we could do a better job of using mechanism to pinpoint how an error got to sentry - the generic category is pretty broad.
We validated that this is not big of a problem so I am closing this until there this problem becomes big enough.