In Event.SetException support errors implementing Unwrap() []error

[kamstrup]

Background

At some point in time Go grew types of errors that do not support the standard errors.Unwrap() function. Notably errors.Join(...) and fmt.Errorf("%w: multiple errors here %w", err1, err2). These errors expose an interface Unwrap() []error. This is also described in the Go documentation: https://pkg.go.dev/errors#Unwrap

This new Unwrap interface is not supported in the Sentry client, leading to not picking up stacktraces correctly for errors that have been wrapped this way.

Description

In this PR I update Event.SetException to support these new "multi-errors".

It is done by implementing a Go-1.23-style iterator unwrapAll(err). The code does currently not use range-over-func so requires no bump in Go dependency; but is ready for that when the language level is bumped one day.

[codecov]

Codecov Report

Attention: Patch coverage is 79.31034% with 6 lines in your changes missing coverage. Please review.

Project coverage is 86.66%. Comparing base (d20dadd) to head (a4bddff).

Files with missing lines	Patch %	Lines
interfaces.go	57.14%	2 Missing and 1 partial ⚠️
util.go	86.36%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1045      +/-   ##
==========================================
- Coverage   86.70%   86.66%   -0.05%     
==========================================
  Files          55       55              
  Lines        5799     5811      +12     
==========================================
+ Hits         5028     5036       +8     
- Misses        629      631       +2     
- Partials      142      144       +2     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[giortzisg]

Hey @kamstrup, thanks for the contribution. From a quick look I had, this breaks issue grouping, although maybe it's unavoidable.

[giortzisg]

Also if we want to support this, we need to properly handle Exception Groups (RFC) and build an error tree for the wrapped errors.

[kamstrup]

Also if we want to support this, we need to properly handle Exception Groups (RFC) and build an error tree for the wrapped errors.

I see - yeah, the problem is tricky to solve in the general case 😅

My main motivation was just to "get stack traces back in our Sentry issues", because we lost them on around ~50% of the generated issues after developers started using errors.Join() and fmt.Errorf() with multiple %ws.

I would expect that the full fledged solution to this issue would take a good while to develop - in which case it might be worthwhile considering some stop-gap solution for any Sentry users with similar problems.

breaks issue grouping

Yeah, maybe. I can't fully wrap my head around how much trouble this will cause 😅 But for our use case issue-grouping is just about entirely broken already for the reasons stated (Unwrap() []error causing stacktraces not to be found). Without stacktraces from the errors the Go Sentry client attaches a default stacktrace from our http handler, which ends up grouping all manner of different issues together.