Skip to content
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

Open
krconv opened this issue May 21, 2020 · 9 comments
Open

Improve Java issue groupings by ignoring generated stack traces #18959

krconv opened this issue May 21, 2020 · 9 comments

Comments

@krconv
Copy link

krconv commented May 21, 2020

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 the GeneratedConstructorAccessor 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.

image
image

@BYK
Copy link
Contributor

BYK commented Oct 26, 2020

@bruno-garcia - what do you think as our resident Java expert? 🙂

@bruno-garcia
Copy link
Member

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?

@mitsuhiko
Copy link
Member

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

@krconv
Copy link
Author

krconv commented Oct 29, 2020

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.

@github-actions
Copy link
Contributor

github-actions bot commented Jan 6, 2021

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 Status: Accepted, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@github-actions
Copy link
Contributor

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 Status: Accepted, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@danrods
Copy link

danrods commented Apr 8, 2021

Having the same issue here. Any update or workaround for this? I'm using sentry-log4j 1.7.30

@bruno-garcia
Copy link
Member

@adinauer perhaps this was addressed too?

@adinauer
Copy link
Member

@bruno-garcia sadly no.

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

Successfully merging a pull request may close this issue.

6 participants