Allow multiple matchers with the same key in fingerprinting rules

[InterstellarStella]

Problem Statement

Currently, when a chained exception happens, the automatic grouping will take into consideration the latest exception. For example, this exception group:

and this one:

Will be grouped together because of DiagnosticCoroutineContextException

However there is benefit to not only separate these two events between RuntimeException and NullPointerException, but to also have different RuntimeException and NullPointerException issues depending on the rest of their stack trace. Therefore, we can't just create a server side fingerprinting rule that will group them based on their title.

However, stack. variables (ie. {{stack.functon}}) will always belong to the topmost frame, which belongs to the latest exception that is causing the problem in the first place (DiagnosticCoroutineContextException), and cannot be used to make more fine-grained server side fingerprinting rules. The user's only choice here is to turn to SDK Fingerprinting.

Solution Brainstorm

It would be very helpful to users if server side fingerprinting could take into consideration both exceptions from the exception group, so that stack. variables can be used to fine tune grouping.

Product Area

Issues

[getsantry]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

[lobsterkatie]

There's some nuance here, and I don't think the example actually illustrates the stated problem, which is about errors with stacktraces. In the example, neither error has a stacktrace, so we're falling back to looking at error message, and in the case of the DiagnosticCoroutineContextException, error message is falling back to error type because there is no message. I'd need a link to the event to see exactly what contributes and doesn't. If there were stacktraces, we'd be using that, from both exceptions.

Nonetheless, it's true that in cases where we're grouping on exception type, we don't have any way to say "give the chain with errors A and B this fingerprint", such that you could then differentiate it from the chain with errors A and C or the chain with errors D and B. (I tried making a rule with two error.type matchers, but we consider the error types in the event individually, and neither one matches both of the two-type rule's types.) This would apply to other matchers, too - you can't have multiple matchers of the same variety within a single rule. To make that work, we'd either have to change our overall logic or special-case when we see two matchers with the same key.

I'm going to leave this open as a feature request for that feature (which I do think would be a good one).

In the meantime, if you want me to look at the example above, please post a link.

[InterstellarStella]

Thanks for taking a look @lobsterkatie , provided examples from the customer's org here.

[vzukanov]

Hey @lobsterkatie ,
Were you able to find any other way to achieve the desired differentiation between errors inside the DiagnosticCoroutineContextException group in this case?

[lobsterkatie]

I think in this case the best bet is to do it on the SDK side, in beforeSend. Our current server-side fingerprinting logic isn't equipped for this, unfortunately.

(If you do go the SDK route, remember that event.fingerprint should be a list, even if it only contains one string.)

[vzukanov]

@InterstellarStella @lobsterkatie , I tried to resolve our issue with SDK fingerprinting, but didn't succeed. Given the amount of time I had spent on this issue, this probably indicates that fingerprinting documentation should be improved.

Then I decided to attempt a hacky solution myself. Tried to change various Throwable's and event's attributes (incl. using reflection), and, eventually, stumbled across this approach which seems to do the trick:

options.beforeSend = SentryOptions.BeforeSendCallback { event, _ ->
     event.exceptions = event.exceptions?.filterNot {
         it.type?.contains("DiagnosticCoroutineContextException") == true
     }                
    event
}

This looks hacky, so I'm not sure this is a good solution, but leaving it here if someone faces a similar problem in the future.

[lobsterkatie]

Thanks for sharing your solution, and for the feedback about the docs. On that latter point, could you say more about what about the docs was confusing?

[vzukanov]

@lobsterkatie . I can't put a finger on the exact issue with the docs of this feature, but, even though I read them thoroughly multiple times, I still can't say that I understand how fingerprinting works, and what the various options do.
I think the best way to explain this feature would be to have several real examples of issues in the system and show how applying different rules, on the server and on the client, will modify the grouping.

[lobsterkatie]

Thanks for that feedback. I'll pass it along to the docs team.

Leaving this open to track the main issue, about the ability to combine matchers in fingerprint rules.