Open Fwang36 opened 1 year ago
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)
this will actually change grouping so it has to be done in the next major
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 -
Link to Zendesk Ticket