Consider deduping errors caught by exception handlers and loggers

[lobsterkatie]

Problem Statement

A user sent this in as grouping feedback but it's actually down to SDK behavior. They were expecting events to be grouped based on the fact that they're "the same error," when in fact what they are is an error being caught by both an exception handler and a logger.

The user is using sentry.java.spring-boot.jakarta version 6.27.0.

Solution Brainstorm

Is this something the SDK could be smart about deduping?

[adinauer]

We already have a DuplicateEventDetectionEventProcessor in place that should filter out such duplicates. It doesn't seem to work here because they don't have an equal Throwable attached to the event and none of the throwables causes are shared.

I just tested it on our Spring Boot 3 Sample and it does deduplicate events. I'm assuming it doesn't work in your example because the stack traces differ. Not sure why that is but maybe it helps them to dig a bit more.

Quickest way for them to get what they want will likely be implementing their own version of DuplicateEventDetectionEventProcessor by looking at our implementation and adapting it to their needs. If they find a generally applicable way to improve the situation for their combination of libraries, PRs are welcome 😉

[lobsterkatie]

I'm assuming it doesn't work in your example because the stack traces differ. Not sure why that is

I'm not a Java expert, but isn't it because the last bit of each stacktrace is either logging code or exception handling code?

they don't have an equal Throwable attached to the event

Does logging code normally get the Throwable which causes the logging? In JS land, these events really are two separate things, an error being caught vs an error being logged. (This happens in JS when, for example, someone has the Console integration enabled, and an error gets logged to the console - the SDK's error-handling instrumentation captures the error directly, and the integration captures the log of the error.) And so in JS, I actually wouldn't expect these to be caught by a straightforward deduper. The idea I was sharing was adding an option for "smart" deduping (which the JS SDK deduper also doesn't currently have), which is to recognize that though these aren't actually the same event, in fact they kind of are the same event, despite some differences in their data.

Anyway, may or not actually be a good idea, or applicable to Java in the same way it might be for JS. This is mostly just my way of passing along a user feedback event the user thought of as grouping feedback but which IMHO is more about the way they're using the SDK.

Quickest way for them to get what they want will likely be implementing their own version of DuplicateEventDetectionEventProcessor by looking at our implementation and adapting it to their needs. If they find a generally applicable way to improve the situation for their combination of libraries, PRs are welcome 😉

Since this came from a user feedback event, there isn't actually an open channel of communication, but hopefully if they're aggravated enough by it they'll find this issue and consider submitting something!