Python 3.11 added Exception Groups (see PEP 654) as a way of aggregating several unrelated exceptions into a single Exception-compatible object
bugsnag-python currently supports reporting Exception Groups, but there's no visibility of the sub-exceptions contained within the group. This is problematic as often the group won't contain enough information to debug the problems that caused it — the contained exceptions should be unrelated, so it's difficult to go from the group → its sub-exceptions
This PR extracts the sub-exceptions from Exception Groups, so that they are reported to bugsnag along with the group. This is very similar to how we report AggregateExceptions in the .NET notifier
Design
In order to avoid truly gigantic lists of errors in the dashboard, we don't recurse into sub-exception groups or their cause/context. The error reporting API also doesn't support tree-shaped hierarchies of errors, so this structure would be difficult to deal with in bugsnag anyway
For example, this exception group:
will be reported as:
This should still contain enough information to debug the errors and, if not, the exceptions can be reported separately by catching the ExceptionGroup itself
Goal
Python 3.11 added Exception Groups (see PEP 654) as a way of aggregating several unrelated exceptions into a single Exception-compatible object
bugsnag-python currently supports reporting Exception Groups, but there's no visibility of the sub-exceptions contained within the group. This is problematic as often the group won't contain enough information to debug the problems that caused it — the contained exceptions should be unrelated, so it's difficult to go from the group → its sub-exceptions
This PR extracts the sub-exceptions from Exception Groups, so that they are reported to bugsnag along with the group. This is very similar to how we report
AggregateExceptions
in the .NET notifierDesign
In order to avoid truly gigantic lists of errors in the dashboard, we don't recurse into sub-exception groups or their cause/context. The error reporting API also doesn't support tree-shaped hierarchies of errors, so this structure would be difficult to deal with in bugsnag anyway
For example, this exception group:
will be reported as:
This should still contain enough information to debug the errors and, if not, the exceptions can be reported separately by catching the
ExceptionGroup
itself