MXCPUException events are incredibly noisy

[dfed]

Platform

iOS

Environment

Production, TestFlight

Installed

Swift Package Manager

Version

8.26.0

Xcode Version

15.4

Did it work on previous versions?

No

Steps to Reproduce

Have MXCPUExceptions thrown in your app – I'm not sure what Sentry flags turn this on or off

Expected Result

MXCPUExceptions on a single page or encountered by a single user within a certain small time period get duplicated into the same issue

Actual Result

When a single user enters a state where their app starts throwing MXCPUException, we get half a dozen issues filed at once. I find myself spending a ton of time going through and duplicating/merging issues. I'm at a point where I want to turn off tracking for this kind of error but I'm not sure which dial to turn.

Are you willing to submit a PR?

No response

[brustolin]

Hello @dfed thanks for reaching out.

The MXCPUException Is triggered by MetricKit, we will work to improve grouping.

In the mean time, if you really wants to disable it:

SentrySDK.start { options in
    //...
    options.enableMetricKit = false
}

[kahest]

@dfed are you on sentry.io and would you be able to share links to the issues you mentioned? You can link them either here or send them to my email [email protected]

[dfed]

I'm not on sentry.io but I'll forward you links shortly. Apologies for the delay!

[dfed]

@kahest here's a list of these kinds of unique events from yesterday, from a single customer, all fired in the same minute:

1. https://portola.sentry.io/issues/5546165459/events/ffb28f35e3de4f7a89f3c23abb50fdc2/?project=4506735735865344
2. https://portola.sentry.io/issues/5546165396/events/e1289d4396b5417095ea324c745331fa/?project=4506735735865344
3. https://portola.sentry.io/issues/5546165641/events/691f4d4c33a24136b7751aef0120ddee/?project=4506735735865344
4. https://portola.sentry.io/issues/5546165638/events/74643b77db7045d8b86905fef9033dde/?project=4506735735865344
5. https://portola.sentry.io/issues/5546165615/events/d7afcc0842b446df9aca1b2376328618/?project=4506735735865344
6. https://portola.sentry.io/issues/5546165649/events/e66b004592a54b808d557a74fb2404f4/?project=4506735735865344
7. https://portola.sentry.io/issues/5546165747/events/5471993c3b754e23b3c401483cfe6fee/?project=4506735735865344
8. https://portola.sentry.io/issues/5546165682/events/2f152834fc3e47a392b11d767f0d15c9/?project=4506735735865344
9. https://portola.sentry.io/issues/5546165717/events/5c598db1da314fd9a17cc9843dd17b51/?project=4506735735865344
10. https://portola.sentry.io/issues/5546165780/events/7996e462071b4d1e8b078fe699908913/?project=4506735735865344
11. https://portola.sentry.io/issues/5546165655/events/db43038b01314b209f2ce5442e44b70c/?project=4506735735865344
12. https://portola.sentry.io/issues/5546165778/events/61022e1c18c8407692168ae1d04150df/?project=4506735735865344
13. https://portola.sentry.io/issues/5546165887/events/9953b15e43f34880b580e56be9591b81/?project=4506735735865344
14. https://portola.sentry.io/issues/5546165838/events/aedbb045f4ca48a2a4dd18cc0d24e1da/?project=4506735735865344
15. https://portola.sentry.io/issues/5546165847/events/0f6a297302ad4f9b945cd967fcef936b/?project=4506735735865344
16. https://portola.sentry.io/issues/5546165958/events/5ca4eebdd5c9453bb51660c6b1e62643/?project=4506735735865344
17. https://portola.sentry.io/issues/5546165814/events/e6d5d3bf42af426b91545782a648fc6d/?project=4506735735865344
18. https://portola.sentry.io/issues/5546166011/events/46de21a846264eab974b7ef39bc628b8/?project=4506735735865344
19. https://portola.sentry.io/issues/5546165882/events/3c31eca726ad4edcad89705ab3cca262/?project=4506735735865344

This kind of barrage of nearly 20 issues at once for the same underlying cause is typical. Every time a customer of ours ends up in MX*Exception land we get another barrage of unique issues. If you search our project for PortolaApp.$main, you'll find more than 160 of these, and any issue created in the same minute as these is almost certainly a duplicate.

Let me know if I can provide more info!

[kahest]

@dfed Thanks a lot, this is definitely helpful. We'll need to investigate and follow up here. Please be aware that due to conferences and PTOs we're currently a bit slower than usual.

[philipphofmann]

@dfed, the quality of the stacktraces depends on MetricKit. The Cococ SDK takes them and parses them to Sentry events. The problem I see is that most of your MXCPUException events have the same title as Sentry uses the inApp frames to determine the title. Still, issue seems to have a different stacktrace for the root cause. Can you post some examples of issues you merged?
I guess if we improved grouping, they would be more actionable. Do you have any suggestions on how you would expect the issues to be grouped?

[dfed]

Apologies for the delay responding! I don't know which issues I've merged at this point.

I just know that without any event grouping the issues filed couldn't be prioritized, and the volume of issues created any time a user entered this exception state meant these alerts were effectively noise.

[philipphofmann]

@dfed, I checked your events again, and I see some top most frames in a package called GameController, that could potentially be inApp, but they aren't. So should these frames be inApp? If yes, maybe you need to add GameController to inAppIncludes or you could change the stacktrace rules in your project, so we mark them as inApp, because then Sentry considers them for grouping.