Spam of Errors from framework

[smeubank]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using? If you use the CDN bundles, please specify the exact bundle (e.g. bundle.tracing.min.js) in your SDK setup.

@sentry/next

SDK Version

7.12.1

Framework Version

13?

Link to Sentry event

No response

SDK Setup

customer provided in another channel

Steps to Reproduce

NextJS applicaiton throwing errors, seems a pattern with hydration errors in particular

Expected Result

Do not receive errors in Sentry which occur within the framework

Errors which do appear in Sentry should not be marked as missing source maps related to framework code

Actual Result

Only receive errors in Sentry (costly to quota) which are questionably relevant for the user

Do not flag issue as missing source maps for framework specific code

[smeubank]

Regarding hydration error spam:
As discussed in the linked issue it is questionable if we can say all hydration errors are useless. What we can do is in product make proactive suggestions to the user on how to get rid of them (if they want) with beforeSend and/or ignoreError

getsentry/sentry#44877

Regarding framework source code:
Framework source code was incorrectly being marked as in app (part of customer code)

fix with this PR: #7097 in release 7.37

marks the stack frames as inApp:false so they're no longer relevant. Most relevant should become useful then

In case framework code IS useful:
There are situations like below where the user may want to upload min framework code. To do so they need to widen scope, this is not default because it increases upload time/size of source maps

So in product similar to above, we need to detect these tpes of stack trace errors based on some pattern

1. suggest they widenScope
2. we can consder marking these as irrelevant frames in SDK inApp:false

In this example to consider, if marking them all as inApp fale, then the stack trace will be empty but they don't have use for the user. You should still be able to see them, by selecting raw stack trace. However it is unclear the logic behind most relevant being selectable

[smeubank]

Just need to update with the outcome of changes from above PRs, and if shipped, and if we can confirm. Should try to find a way to quantify the impact

[lforst]

Superseded by #7432