With chained errors, which one counts as the main one?

[lobsterkatie]

There have been a number of issues which have come up lately having to do with which one of a chained set of errors we use for the purposes of grouping, titling an issue, calculating stack.module, etc. In many cases, what we're doing is the opposite of what the user expects, i.e., we're picking the wrong error to use. Here are a few examples:

• About how we title an issue: https://github.com/getsentry/sentry/issues/64074
• About how we automatically group issues: https://github.com/getsentry/sentry/issues/59679
• About how we use custom fingerprints when grouping issues: https://github.com/getsentry/sentry/issues/63882
• About how we assign mechanism data and describe errors in log messages: https://github.com/getsentry/sentry-javascript/issues/10851

To solve this we need to:

• Decide for sure which error in a chain it makes sense to use. It's possible this may differ by platform, but within a platform, we should be consistent everywhere across the product. In addition to the top-of-the-chain/bottom-of-the-chain question, we also might want to consider the in-app-i-ness of the frames in each error's stacktrace.
• Find all the places where we handle chained errors and have to make that determination. In some instances, the choice will be based on the value of main_exception_id, which is calculated based on an is_exception_group value sent by the SDK. (See here for details.) There may be other places where we determine that, too, though (if we're hardcoding to always look at the top error or the bottom error, for example), so we should make sure to find those as well.
• Where we're making the wrong choice (according to our agreement in step 1), update the code and/or get the SDK to send a different main_exception_id value.

Semi-related: In some cases we may want to reverse the order of the linked errors before we decide which one to use. (In those cases, we'd do this rather than just make a different choice because the order affects things like how the chain of errors is displayed in the UI.) See https://github.com/getsentry/sentry/issues/64087.

[lobsterkatie]

Just wanted to highlight part of @markushi's comment on https://github.com/getsentry/sentry-java/pull/3184, as I think it's an interesting idea to consider vis-à-vis titling. (The whole thread there is relevant and worth reading, but didn't want to lose track of this idea in particular.)

Are the error message and stacktrace of the wrapper error always the same and/or do they provide any informational value?

Whilst the wrapped exception itself and it's stacktrace don't provide any extra information, it indicates one crucial semantic information: An app crash is about to happen.

Thinking more about future solutions: I'm wondering if in situations where the wrapping exception contains no in-app frames, we simply could decide to just use the inner exception for titleing.

[lobsterkatie]

More discussion of the above: https://github.com/getsentry/sentry/issues/62299#issuecomment-1971939190

[armenzg]

An example of picking the title from the cause error.