Stack Trace Trimming is trimming relevant frames

[Fwang36]

Link to Jira with customer information.

Environment

Ruby Rails.

Expected Result

Frames are trimmed from the middle while leaving the top and bottom alone.

Actual Result

Long Stack Trace for an event is trimming frames starting from the second frame. Some frames trimmed seem to be "in_app".

Trimmed frames are causing issues with our CODEOWNERS feature. Customer states -

that the trimmed frames (which do not appear in Sentry) contained information that would have correctly resulted in the assignment of the issue to another team, if they were present. In the example I gave, a large number of frames which were adjacent to the top of the stack were removed. These deleted frames were the most relevant in terms of ownership.

Link to Zendesk Ticket

[jjbayer]

Scoping: don't solve the "in-app" problem, only the "trimming from the middle" problem.

[jjbayer]

@sl0thentr0py I might need some Ruby help here:

Long Stack Trace for an event is trimming frames starting from the second frame.

In the event linked from the Jira issue, the second frame seems to contain the yield keyword, which does not appear in the stack trace that the user submitted (also in Jira issue). The puma web server seems to be concurrent. Could it be that the stack trace that Sentry sees is the raw stack trace from the web worker, while the stack trace the user sees is the logical, concurrent thread across workers (or vice versa)?

[sl0thentr0py]

Frames are trimmed from the middle while leaving the top and bottom alone.

This truncation behaviour was decided here a while ago since we thought that's better UX than trimming from one side.
#1807 (comment)

The puma web server seems to be

I don't think this is about puma, it seems to me the stacktrace they reported comes from a different environment (where graphql.trace is turned off).

Either way, this is entirely an SDK issue so you can transfer this to sentry-ruby.