Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

RFC: Sentry Issues with missing stack traces #5334

lforst started this conversation in RFCs
Discussion options

You might have noticed in Sentry, when browsing through your issues, that some of them do not have a stack trace attached. A common issue type where this happens is, for example, on TypeError: Failed to fetch errors.

You've probably seen it before:

Example failed to fetch error

We generally do not like issues without stack traces because they mess up Sentry's fingerprinting/grouping algorithm: All the issues that share a name and do not have a stack trace are now grouped into the same issue - even when the errors might come from completely different places in your application! It sucks trying to fix these errors when you don't know where they happen. Additionally, it's impossible to know which ones are the most important because all of them are grouped into one, so you can't see the event count of individual errors!

We want to fix this.

As part of our initiative to improve the workflow and grouping on Sentry (https://github.com/getsentry/sentry-javascript/milestone/17, getsentry/sentry#34327) we want to resolve this issue once and for all (or at least improve it step by step).

Currently, we're investigating what class of errors doesn't have stack traces.
We suspect that it is mostly related to fetch in some way, but we're not sure if this covers all instances.

Anybody can help us to solve this issue!

As we're trying to figure out what causes errors without stack trace, anybody can help us investigate by sharing experiences surrounding the issue:

  • Have you ever encountered errors in Sentry without a stack trace?
  • Were you able to resolve errors without stack trace when you encountered them?
  • Have you noticed a pattern for errors without stack trace?

Next steps

You must be logged in to vote

Replies: 6 comments 6 replies

Comment options

Is this only happening in the browser environment?

Are you able to replicate the issue?

Not sure if you have a list of existing issues like that or we would use this issue thread to share it

You must be logged in to vote
3 replies
Comment options

For now we are focusing on the browser environment. We do have some issues internally we are looking at, but we also want to reach out to see what others experience.

Replication is tough - we are tracking work toward that in #5335

Comment options

In #4146 I've mentioned one way how this can be reproduced:

To clarify, I'm talking about when request has failed to be dispatched, not when the request finishes with an error code (that doesn't report a Sentry event normally). So for example when the URL is blocked through the Developer tools "block url" functionality (easy to test with).

Comment options

In #4146 I've mentioned one way how this can be reproduced:

To clarify, I'm talking about when request has failed to be dispatched, not when the request finishes with an error code (that doesn't report a Sentry event normally). So for example when the URL is blocked through the Developer tools "block url" functionality (easy to test with).

@rchl That's awesome input. Thank you!

Thinking about this, we should also investigate whether any browser extensions that block requests generate similar errors.

Comment options

In addition to fetch errors, there's also the case where someone or something rejects with a non-Error object (or even with a string).

You must be logged in to vote
0 replies
Comment options

Ideally the error would provide a stack trace and the URL that was requested at least (currently can only be deduced from the breadcrumb integration).

You must be logged in to vote
1 reply
Comment options

timfish Jul 28, 2022
Collaborator

I think I've seen fetch throw similar useless errors for CORS mismatches too.

I had always assumed the missing stack traces were something to do with the issues surrounding how they opted for zero-cost async stack traces but these fetch errors have no stack lines at all so it's probably not the case.

If this is something that only affects fetch we could capture the stack trace and use on error if the stack is missing later but that's a pretty heavy handed approach!

Comment options

@lforst it is not only fetch, and it would be awesome if you fix it!

Have you ever encountered errors in Sentry without a stack trace?

Oh, yeah!

Were you able to resolve errors without stack trace when you encountered them?

Maybe some, but I have one which I am really struggling to fix without an error trace, and that was what brought me to search and find this RFC :(

Have you noticed a pattern for errors without stack trace?

The error which haunts me is InvalidStateError: Failed to start the audio device coming from Web Audio API. I only experience it in Webkit on iOS (I have some React Native apps, which are running internal HTTP server, and display some stuff it serves inside Webkit browser, that's why localhost in the screenshots). And it is a tricky one to fix without stack trace, as it happens rarely and randomly, so without stack traces I am still trying to figure out what call(s) to the Web Audio API cause it, and under what unfortunate conditions it happens.

2022 09 03 - screenshot

You must be logged in to vote
2 replies
Comment options

timfish Sep 4, 2022
Collaborator

The attached events mechanism is unhandledrejection and these do not include a stack trace because the stack information is gone by the time the error is thrown.

I believe it's possible to patch/extend Promise to record stack traces every time a Promise is created which can later be used to help construct a full stack trace in the case of later rejection. However this adds a lot of overhead for the rare case of rejection so you would probably not want to use this in production.

I think this issue/discussion is about errors that unexpectedly have missing stack traces whereas this is expected for unhandledrejection.

Comment options

I've seen some errors with unhandledpromiserejection mechanism that did include some code location, and in my understanding if a Promise was rejected with an instance of Error, it should include some stack trace anyway? Maybe not a 100% clear one, but at least something to look at?

Comment options

Have you ever encountered errors in Sentry without a stack trace? Yes
Were you able to resolve errors without stack trace when you encountered them? No

These errors happen occasionally and I pretty much get no information regarding this error. All i could see is a fetch request marked with severity "Error". Logging at least the status code or the issue behind it might be useful.

You must be logged in to vote
0 replies
Comment options

@lforst
Is there any progress on that? I am using 7.57.0.
I'd like to know what's the url of the fetch, what arguments were provided in the body or query and what's the status code from the server.

image

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
RFCs
Labels
None yet
Converted from issue

This discussion was converted from issue #5333 on June 29, 2022 10:13.

AltStyle によって変換されたページ (->オリジナル) /