Codecov Report

Attention: Patch coverage is 80.00000% with 24 lines in your changes missing coverage. Please review.

Project coverage is 87.63%. Comparing base (3f8357e) to head (80e7f9e).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2803      +/-   ##
==========================================
- Coverage   87.78%   87.63%   -0.16%     
==========================================
  Files         269      270       +1     
  Lines        8971     9032      +61     
==========================================
+ Hits         7875     7915      +40     
- Misses       1096     1117      +21     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Android Performance metrics 🚀

iOS Performance metrics 🚀

Couple of merge conflicts are here, prolly because of the mutable data PR

@buenaflor So i tested on Android emulator. While both exceptions are shown, the order is reversed. Which would suggest that the relationships build here are ignored, no? The json has the references in the mechanism, so this should all be correct. Is this feature activated on sentry.io?

https://sentry-sdks.sentry.io/issues/6182166435/events/latest/?project=5428562&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=latest-event&stream_index=0

@denrase not sure how the order is supposed to be

but regarding the UI, it should look like this (or used to)

I triggered the platform exception with the implementation of this PR #1998

Not sure if they removed this UI change

From the docs: https://develop.sentry.dev/sdk/data-model/event-payloads/exception/
Multiple values represent chained exceptions and should be sorted oldest to newest so I believe the second picture is correct? runtime exception -> platformexception

@denrase there's also a couple dartt analyzer warnings

@buenaflor So the first picture is according to the RFC, where the root is the last in the list.

as discussed let's check the mentioned PR if we added something wrong to make the UI look like in my comment

"exception":
{
    "values":
    [
        {
            "type": "PlatformException",
            "value": "PlatformException(error, Catch this platform exception!, null, java.lang.RuntimeException: Catch this platform exception!\n\tat io.sentry.samples.flutter.MainActivity$configureFlutterEngine$1.onMethodCall(MainActivity.kt:38)\n\tat io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:267)\n\tat io.flutter.embedding.engine.dart.DartMessenger.invokeHandler(DartMessenger.java:292)\n\tat io.flutter.embedding.engine.dart.DartMessenger.lambda$dispatchMessageToQueue$0$io-flutter-embedding-engine-dart-DartMessenger(DartMessenger.java:319)\n\tat io.flutter.embedding.engine.dart.DartMessenger$$ExternalSyntheticLambda0.run(Unknown Source:12)\n\tat android.os.Handler.handleCallback(Handler.java:942)\n\tat android.os.Handler.dispatchMessage(Handler.java:99)\n\tat android.os.Looper.loopOnce(Looper.java:201)\n\tat android.os.Looper.loop(Looper.java:288)\n\tat android.app.ActivityThread.main(ActivityThread.java:7924)\n\tat java.lang.reflect.Method.invoke(Native Method)\n\tat com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)\n\tat com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)\n)",
            "mechanism":
            {
                "type": "chained",
                "exception_id": 1,
                "parent_id": 0,
            }
        },
        {
            "type": "RuntimeException",
            "value": "Catch this platform exception!",
            "mechanism":
            {
                "type": "sentry-flutter",
                "is_exception_group": true,
                "exception_id": 0
            }
        }
    ]
},

Above is what we get from the PR of @ueman. We have a PlatformExcetion, which contains an exception that occured in Android. We parse this either from details or stackTrace:

PlatformException(
  details: null,
  stackTrace: RuntimeException(...)
)

The RuntimeException is the innermost, so in this example it is the root and last in order.

PlatformException(id: 1, parent: 0), RuntimeException(id: 0, parent: null),

What does not make sense to me is is_exception_group: true in this example, as there are not multiple children on the same level. But only if we set this value, we have the UI which shows hierarchy.

In tests we have the case where both details and stackTrace:

PlatformException(
  details: SomeException(...),
  stackTrace: RuntimeException(...)
)

I'm not sure that this is a case that occures, but since we have a test case for it, I'm assuming that we need to handle it.

But what would in this case the structure look like? Initially, I have implemented it the other way around, where PlatformException is the root and also a group, as it contains two children on the same level:

RuntimeException(id: 2, parent: 0), SomeException(id: 1, parent: 0), PlatformException(id: 0, parent: null),

But seeing the other PR, I don't think that is correct.

So in summary:

• I think the PR of @ueman is correct where the innermost exception is the root. Actually I'm not sure anymore, just did an error with PlatformException as root, but sentry took the innermost RuntimeExcetion for the title: https://sentry-sdks.sentry.io/issues/5141932961/events/latest/?project=5428562&query=is%3Aunresolved%20issue.priority%3A%5Bhigh%2C%20medium%5D&referrer=latest-event&stream_index=0
• But if so, i don't know how to build the hierarchy with both details and stackTrace populated with an error.

based on JS and Python impl the root / parent should be marked with is_exception_group: true, in this case the PlatformException

But if so, i don't know how to build the hierarchy with both details and stackTrace populated with an error.

FWIW, that's not a case I've ever seen in production. It's either in details or in stackTrace, but not both. I would suggest to not handle the case where both contain an exception and wait until someone complains and then care about it.