Problem Statement

Typically, we are used to exceptions having a linear relationship to one another (an exception causes another, which causes another). We represent this by allowing folks to send in a list of exceptions for error events.

In several languages though, there is this idea of AggregateExceptions. With AggregateExceptions, we have error relationships where an AggregateException has multiple causes (a 1 to N relationship).

This was initially raised by @mortargrind in getsentry/sentry-javascript#5469, borrowing their example below:

Legend:

• Error1 => Error2 means Error1 caused by Error2 (handled by existing Sentry data model)
• Error1 [Error2, Error3] means Error1 aggregates Error2 and Error3 (would be handled by the hypothetical AggregatedErrors)

Sample error chain:

HighLevelError => AggregateException [LowLevelError1, LowLevelError2 => LowerLevelError1, LowLevelError3] => LowestLevelError

Typically these AggregateExceptions are produced when you have futures/async await/coroutines, so a set of tasks (and their possible exceptions) getting associated by the callee of the tasks.

There is no way in Sentry to represent the relationship between these errors.

Examples:

• AggregateException in .NET
• AggregateError in JavaScript
• Python ExceptionGroups - PEP 654
• Wrapping multiple errors in Go 1.20

UPDATE

This feature is coming soon. Here is the list of items being tracked to complete it.

# Sentry Backend & Relay
- [ ] getsentry/relay#2020
- [ ] #47643
- [ ] #48653 

# Sentry UI
- [ ] #47176
- [ ] #48167
- [ ] #48527

# SDKs
- [ ] getsentry/sentry-python#2025
- [ ] getsentry/sentry-dotnet#2287
- [ ] getsentry/sentry-javascript#5469

# Misc
- [ ] https://github.com/getsentry/rfcs/pull/79
- [ ] https://github.com/getsentry/develop/issues/932
- [x] [Public announcement](https://changelog.getsentry.com/announcements/exception-groups-now-supported-for-python-and-net)
- [ ] https://github.com/getsentry/sentry-docs/issues/7501