Objc exceptions with no in-app frames group poorly

[jboulter11]

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

https://dropbox.sentry.io/issues/5135362741/events/f9b8e7ac1aa94c56a3283501d358654f/?project=4505546600087552

Here's an example of the issue. Note the group has many different crashes with different, unrelated traces. Grouping shows it's grouping on objc_exception_throw which is not in-app. It's not a good piece of context, really, especially since the exception type already indicates a thrown exception.

I think this should probably be changed at the Sentry level.

Expected Result

I'd like these exceptions to either:

1. Group by message
2. Group by out-of-app stack frames which are actually relevant to the issue.

When I added the following rule to our grouping rules, it seems to have resulted in group by message for these problematic groups at the cost of regrouping a lot of other stuff. https://dropbox.sentry.io/issues/6978111173/?project=4505546600087552

stack.function:objc_exception_throw -group

Actual Result

The issue is over-grouped, meaning there are many unrelated bugs in one group. Anything without in-app frames that also matches the exception type is all in one group.

Product Area

Ingestion and Filtering

Link

https://dropbox.sentry.io/issues/5135362741/events/f9b8e7ac1aa94c56a3283501d358654f/?project=4505546600087552

DSN

No response

Version

No response

[linear]

ENG-5775

[getsantry]

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

[lobsterkatie]

Took a look at the issue you linked and I see the behavior you're talking about, though I don't yet understand exactly how our grouping algorithm is getting there, given the built-in rules we have. I'm going to do a little experimentation to see if I can make the behavior make sense and will get back to you with what I find.

[lobsterkatie]

Okay, I've tracked down the problem. In almost every place where we use ^-group in our built-in stacktrace rules, we also use -group. (In other words, whenever we exclude everything after the frame, we also exclude the frame itself.) The one exception to that is here, where we handle code that throws. (If you search for throw in that file, you can see the functions which fall into that category.) I believe this is an oversight, which we should fix.

So as not to cause a bunch of new groups for folks, I'm going to include this change in a new grouping config I happen to currently be working on. That should be released in the next few weeks, and I can update here once it is.

[lobsterkatie]

UPDATE: Made the change here, though it won't go live until we actually switch to using the new config in a few weeks. I also realized that your case hits a longstanding known limitation in our system. I go into more detail in the description of that PR, but TL;DR, if you hadn't already put that custom rule in place, without some workaround you wouldn't have been able to see the effects of my change on existing issues even once the new config is released.

Because you did add the rule, you're actually fine, but I mention this in case you run into the same problem with other throwing functions, or in case someone else lands on this issue with the same problem. In that case, possible workarounds are:

• Add a rule like the one you mentioned above for the throwing function in question, because that will override our built-in logic and force the change.
• If it's after the new config is released, delete the offending group to force the hashing process to start from scratch with the new config.
• Either before or after the new config is released, manually unmerge the mismatched events.

I'll update here again once we do actually do that release.