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.