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
Improve Java issue groupings by ignoring generated stack traces #18959
Comments
@bruno-garcia - what do you think as our resident Java expert? 🙂 |
The PR adding that is here: https://github.com/getsentry/sentry/pull/13305/files @mitsuhiko is this still the approach we take in this case? Could one replicate that PR and add these new types? |
@bruno-garcia on this case clear cut: change the existing file. The grouping code is obviously crap in this case. If it were more debatable we might require a new revision with explicit upgrade. |
Also wanted to mention that I believe my org has some custom utilities built on top of the Java client to help with grouping; if you think that might be part of the problem here, I'm glad to take a look. It seems that the problem is that generated class name, but I'm not that familiar with what is done client-side. |
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
This issue has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
Having the same issue here. Any update or workaround for this? I'm using |
@adinauer perhaps this was addressed too? |
@bruno-garcia sadly no. |
Summary
In #13304, Sentry started ignoring stack traces that came from the
jdk.internal.reflect.GeneratedMethodAccessorXX
class because it was causing errors in Sentry to create a new Issue ever time it was thrown (the culprit or transaction would have a random number in it, and would change each time). This request is to also ignore theGeneratedConstructorAccessor
class (i.e.jdk.internal.reflect.GeneratedConstructorAccessorXX
) from stack traces.Motivation
Why should this be worked on? What problems or use cases does it solve or improve?
This helps engineers stay organized in situations where the third-party packages they are using are generating exceptions using reflection. The package we use is the Java SOAP API client for Salesforce, which ends up filling our Sentry homepage with issues and producing noisy alerts.
Additional Context
Any other context or screenshots or API request payload/responses that you pertain to the feature.
Here is what our dashboards and Slack alerts look like.
The text was updated successfully, but these errors were encountered: