fix: Trim long stacktraces

[szokeasaurusrex]

Only process and send the first 300 stack frames for an error event. This prevents the SDK from causing the program to hang when the SDK captures an error with a very large number of stack frames. Relay anyways trims events to 250 stack frames, so it is pointless for us to process much beyond that number.

Fixes #2764

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.32%. Comparing base (ec2d929) to head (df00c7d).

:white_check_mark: All tests successful. No failed tests found.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #3795 +/- ## ========================================== + Coverage 84.30% 84.32% +0.01% ========================================== Files 137 137 Lines 14561 14564 +3 Branches 2460 2460 ========================================== + Hits 12276 12281 +5 + Misses 1528 1525 -3 - Partials 757 758 +1 ``` | [Files with missing lines](https://app.codecov.io/gh/getsentry/sentry-python/pull/3795?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=getsentry) | Coverage Δ | | |---|---|---| | [sentry\_sdk/consts.py](https://app.codecov.io/gh/getsentry/sentry-python/pull/3795?src=pr&el=tree&filepath=sentry_sdk%2Fconsts.py&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=getsentry#diff-c2VudHJ5X3Nkay9jb25zdHMucHk=) | `99.52% <100.00%> (+<0.01%)` | :arrow_up: | | [sentry\_sdk/utils.py](https://app.codecov.io/gh/getsentry/sentry-python/pull/3795?src=pr&el=tree&filepath=sentry_sdk%2Futils.py&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=getsentry#diff-c2VudHJ5X3Nkay91dGlscy5weQ==) | `85.94% <100.00%> (+0.01%)` | :arrow_up: | ... and [2 files with indirect coverage changes](https://app.codecov.io/gh/getsentry/sentry-python/pull/3795/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=getsentry)

[sl0thentr0py]

please make sure that this is trimming from the correct side of the backtrace since there's a lot of weird reverses in the pipeline from SDK -> ingest -> final persisting

[szokeasaurusrex]

@sl0thentr0py looks like actually this is trimming from the wrong end of the backtrace (the final calls will get trimmed, when in fact, they are probably the most interesting to the user). Thanks for the good catch!

The problem is that I don't think there is a straightforward way to iterate the stack trace in the reverse order. Iterating through the entire stack trace to get the last 300 (or other limit) entries, when the stack trace is very large, is not a good idea though, since the slowness causing https://github.com/getsentry/sentry-python/issues/2764 seems to stem from the iteration.

So, perhaps we can set a larger stack trace limit (e.g. 1000 frames), and if this is exceeded, we would just drop the stack trace completely from the event? What do you think?

We should also perhaps confirm which end of the stack trace Relay is trimming. Likely we want to be doing the same thing as them.

[Dav1dde]

We should also perhaps confirm which end of the stack trace Relay is trimming. Likely we want to be doing the same thing as them.

Relay is trimming not the end of the stracktrace but for recursions the middle on a best effort basis.

[jan-auer]

is there any way we can or should indicate to Relay that we have trimmed the stacktrace?

Yes, this can be done through the len field on the corresponding meta entry for the frames field in the stack trace. For example, in an exception's frames, this would be set on meta for exception.values[0].stacktrace.frames.

However, this information will not be shown in the UI at the moment. If you want to display this to a user, this needs to be added to the issue details UI.

Edit: For the time being, I'd suggest not to do any of this. Since the UI won't show trimmed stack traces and the future of using _meta is uncertain, let's try to go without that additional information. If we get a strong indication from users that such meta data is needed, let's please revisit this.