RFC: Sentry Issues with missing stack traces

[lforst]

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:

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

• Identify the problem (Tracked in Identify how errors without a stack trace happen #5335)
• Reproduce the issue consistently
• Brainstorm how to provide a stack trace for errors without

[yordis]

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

[AbhiPrasad]

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

[rchl]

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).

[lforst]

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.

[lobsterkatie]

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).

[rchl]

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).

[timfish]

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!

[birdofpreyru]

@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.

[timfish]

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.

[birdofpreyru]

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?

[s-ashwin]

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.

[filipkowal]

@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.