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

[szokeasaurusrex]

@jan-auer, is there any way we can or should indicate to Relay that we have trimmed the stacktrace? @Dav1dde was saying that this might be possible to do via the _meta field.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            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	Coverage Δ
sentry_sdk/consts.py	99.52% <100.00%> (+<0.01%)	⬆️
sentry_sdk/utils.py	85.94% <100.00%> (+0.01%)	⬆️

... and 2 files with indirect coverage changes

[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 #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.