Increase maxErrorDepth or use lowest wrap first

[yonderblue]

Issue

For projects that make liberal use of error wraps, the 10 depth limit is restrictive. This is mainly because it chops the lower wraps and keeps the top which are the less specific locations, often just shared boilerplate.

Solution

Increase the depth a lot, or don't reverse the event.Exception (https://github.com/getsentry/sentry-go/blob/master/client.go#L419), or better yet do both. Perhaps making this configurable would be useful.

[rhcarvalho]

Hi @yonderblue do you have an example Sentry event where the limit affects interpreting the issue?

---

or don't reverse the event.Exception

The reversing is done as part of Sentry's ingestion protocol, the server expects a well-defined order.

This does not limit how you see the chain of errors in the UI, though, as that is a user setting you can change.

1. Go to User settings
2. Choose "Most recent call last"

Regardless of your user setting, you can always toggle the order in the issue view if you need a one-off change:

[yonderblue]

@rhcarvalho thanks I didn't realize there was a user setting for the default order, that solves that.

However the max depth causes a loss of needed info, especially since it stops unwrapping lower errors where the most important information is. I would recommend setting it to something just as a safe guard (eg 100) and if it exceeds that, putting a fake "exceeded max" Exception into the event.Exceptions so the user is aware.

[rhcarvalho]

I didn't realize there was a user setting for the default order, that solves that.

Glad it helps :)

However the max depth causes a loss of needed info, especially since it stops unwrapping lower errors where the most important information is. I would recommend setting it to something just as a safe guard (eg 100) and if it exceeds that, putting a fake "exceeded max" Exception into the event.Exceptions so the user is aware.

👍

Do you have an example from sentry.io you could share?

I like the idea of marking the event when the limit is reached. We normally have similar marks for processing errors.

Growing the limit needs some care, too large events can be discarded during ingestion and a chain of 100 errors in Sentry would look very messy. At that point, it would probably be more helpful to do something else. That's why I'm trying to understand what kind of deep-nested errors you're dealing with.

[yonderblue]

Sorry I don't have any publicly visible examples, however it isn't hard to imagine a stack deeper than 10 items. Often the boilerplate/framework/middleware kind of things eat 5 or so items at the top. Just moving the limit to 20-30 would likely be sufficient with the extra notification frame for it going over.

I am curious what messy part in the UI you're referring to? I tested with 30 or so frames and it looked fine to me (with the other PR that only does 1 frame for xerrors). Although I can understand perhaps there are some performance hurdles the larger the stack.

[yonderblue]

user setting for the default order, that solves that.

@rhcarvalho actually it only partially solves it, because even with fingerprinting to something else, what is in the issue list still shows the type from the top of the stack, instead of the bottom as I would wish.

Is there anything that will break if I simply don't reverse the exception order?

[rhcarvalho]

@yonderblue hey, sorry I'm OoO with limited connectivity. Until Sentry's backend would support customizing the title of issues, what you can do in the short term is indeed mutate the event in BeforeSend to produce your desired outcome. In January, we can look into what would it take to accept custom titles.

In any case, you can try reaching out to folks at the Sentry forum or Discord (or of course official support) if you need help.

Thank you for using our product and contributing with us!

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀