getsentry
Stack Trace Trimming is trimming relevant frames
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.
Scoping: don't solve the "in-app" problem, only the "trimming from the middle" problem.
@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)?
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. https://github.com/getsentry/sentry-ruby/pull/1807#issuecomment-1121849127
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.
ok so this led to discovering a bunch of inconsistencies in trimming etc :) (sigh)
- on the SDK, we take 250 frames on each side, so total 500
- relay however takes only the first 250 of those
- ~ruby seems to be one of several languages that sends the stacktrace in a reverse order than what sentry expects (built primarily with python in mind)~ sorry this was my bad, ordering is fine as per docs
this will actually change grouping so it has to be done in the next major