With chained errors, which one counts as the main one?
- Dominant language
- Python
- Stars
- 44.8k
- Forks
- 4.9k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 624
Description
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](https://github.com/getsentry/sentry/issues/59679#issuecomment-1815286406) 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.
Contributor guide
Assessment
This issue has not been assessed yet.