Excluding proxy classes from stack trace

[svetlana-nikitina]

Hi, we are running sentry java sdk on play framework ver. 2.6.5 with Java 1.8

<dependency>
    <groupId>io.sentry</groupId>
    <artifactId>sentry</artifactId>
    <version>3.1.1</version>
</dependency>

and experience an issue that the guice-enhanced proxies are apparently the parts of the stack trace fingerprint calculation, so we have a lot of detached events:

I see some old tickets which in the legacy SDK which used to solve the problem: #516
but don't see anything in the new sdk

Is it supported? How the issue be fixed?

[marandaneto]

hey @svetlana-nikitina thanks for raising this.

does it help if you add those packages as inAppExclude via SentryOptions.addInAppExclude(package)? thanks!

[bruno-garcia]

Dupe: getsentry/sentry#21645

[svetlana-nikitina]

it don't think it's possible , because of:

1. InAppInclude has the higher prio over InAppExclude
   so if i do:
   SentryOptions.addInAppInclude("my.app.package")
   this has higher prio over:
   SentryOptions. addInAppExclude("my.app.package.whatever.package.under.main")
   so adding addInAppExclude is just ignored
2. even if it was not ignored, i cannot provide regexp here which i basically need:
   SentryOptions. addInAppExclude("EnhancedByGuice")

However after paying around with sentry UI seems like it've fixed it Custom Grouping Enhancements section by this rule:

stack.module:*EnhancerByGuice* -group
stack.module:*EnhancerByGuice* -app

However I should say that Java documentation is a disaster, as all examples and explanations are about JS, not Java: https://docs.sentry.io/platforms/java/data-management/event-grouping/grouping-enhancements/

[maciejwalkowiak]

Thanks @svetlana-nikitina for feedback. We are working on making docs better. If you have something specific to add or change you are welcome to suggest changes in https://github.com/getsentry/sentry-docs/

[maciejwalkowiak]

We could bring the same blacklisting logic as in 1.x:

private static final Pattern IN_APP_BLACKLIST = Pattern.compile("\\$+" // match $ (one or more)
        + "(?:" // start outer group
        + "(?:EnhancerBy[a-zA-Z]*)"  // Match Enhancer classes
        + "|(?:FastClassBy[a-zA-Z]*)" // Match FastClass
        + "|(?:HibernateProxy)" // match Hibernate proxies
        + ")\\$+"); // end outer group and match $ (one or more)

What do you think @bruno-garcia?

[mitsuhiko]

Generally at this point I think we should fix this on the server with improved default stack trace rules rather than in the SDKs themselves.

[bruno-garcia]

For reference, where this exists on the server: https://github.com/getsentry/sentry/blob/master/src/sentry/grouping/enhancement-configs/[email protected]

We'll add a platform: https://github.com/getsentry/sentry/blob/c62499d1de8414e119e8a199eee4c73a01393e44/src/sentry/stacktraces/platform.py

Testing snapshots are here: https://github.com/getsentry/sentry/blob/master/tests/sentry/grouping/fingerprint_inputs/fingerprint-native.json

Make sure cargo-insta snapshot library is installed: cargo install cargo-insta.
make test to verify

[adinauer]

@mitsuhiko how should we proceed with this?

[buckett]

I think we are hitting the same issue whereby stack traces aren't getting matched up because of the hibernate proxies not matching, in our case the proxies are:

    at org.hibernate.proxy.ProxyConfiguration$InterceptorDispatcher.intercept(ProxyConfiguration.java:95)
    at uk.ac.ox.ctl.usermanagement.model.User$HibernateProxy$oRWxjAWT.toString // This is what is causing the problems
    at uk.ac.ox.ctl.usermanagement.model.EnrolmentsSIS$SISWriter.write(EnrolmentsSIS.java:36)

There seems to have been discussion about this a few years ago but things have stalled, the suggestion by @svetlana-nikitina of using the custom grouping is now documented on https://docs.sentry.io/product/data-management-settings/event-grouping/stack-trace-rules/ and looks to still be possible. Having the ability to customise this is good, however having it work out of the box for common use cases is much better. Filtering out dynamic classes generated by common frameworks seems like a sensible default to enable for everyone.

[adinauer]

We have a PR to improve fingerprinting of the stack traces mentioned here: getsentry/sentry#45185

Thanks for the feedback.