Skip to content

Identify how errors without a stack trace happen #5335

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
4 tasks
lforst opened this issue Jun 29, 2022 · 5 comments
Closed
4 tasks

Identify how errors without a stack trace happen #5335

lforst opened this issue Jun 29, 2022 · 5 comments

Comments

@lforst
Copy link
Member

lforst commented Jun 29, 2022

For context: #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 fetch scenarios to check stack trace
  • Analyze errors across browsers
@yordis
Copy link
Contributor

yordis commented Jun 29, 2022

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.

@smeubank
Copy link
Member

smeubank commented Aug 1, 2022

idea: (not mine) always throw a stack trace

@armenzg
Copy link
Member

armenzg commented Sep 13, 2022

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.

image

image

@lobsterkatie
Copy link
Member

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.

@vladanpaunovic
Copy link
Contributor

We validated that this is not big of a problem so I am closing this until there this problem becomes big enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants