Errors appear to be reversed

[calummoore]

Environment

0.30.0

Steps to Reproduce

1. Create multiple wrapped errors using thiserror::Error: e.g. OuterError::HTTPError(InnerError::CollectionHasNoAST)
2. Call sentry::capture_error(&error);
3. View in Sentry console

Expected Result

Errors go from more specific (lower/inner) to more vague (higher/outer)

CollectionHasNoAST -> HTTPError

Actual Result

HTTPError -> CollectionHasNoAST

Console

Workaround

I currently reverse the errors back, and now errors make sense in the console:

let mut e = sentry::event_from_error(err);
// Reverse the errors
e.exception.values.reverse();
sentry::capture_event(e);

[Swatinem]

I believe you are right!
The docs are a bit vague on how this should be handled: https://develop.sentry.dev/sdk/event-payloads/exception/

Multiple values represent chained exceptions and should be sorted oldest to newest.

I will double-check with the rest of the SDK team to find a definitive answer.

[Swatinem]

Checking with other SDKs, this seems to be consistent at least with the Python SDK, which is more of a reference SDK than the Rust one.

No matter which way chained errors are sorted, they will still group into individual issues for each unique chain, which is good.
The problem is that neither sorting direction is particularly useful.

You either end up with your catch-all anyhow::Error as the label in sentry;
Or you end up with io::Error which I bet is a very common leaf error.

Neither of these two options is useful. :-(

[calummoore]

io::Error is definitely more useful than anyhow::Error. And if the user wants something more useful that io:Error they can wrap it in a struct CannotReadSomething(io::Error) and unless they add it as source it won't be the last item CannotReadSomething would be.