Fix Source Code Extraction to Stack Traces (regression via rails) #2472
Comments
|
minor clarification: Also, we may shown context_lines for all frames at some point... |
|
we already support this since forever sentry-ruby/sentry-ruby/lib/sentry/interfaces/stacktrace.rb Lines 65 to 66 in a9b3687 but it is true that some vendor frames are missing context lines in the final product, I will investigate why this is happening. |
|
alright, not technically a regression on our end but at some point rails added this default backtrace gem path cleaner that causes our source code reading to fail since instead of paths like we get paths like I will think of the best way to fix this since technically this affects all grouping now if I suddenly remove that gem filter.. |
|
in the meantime, if they want to fix this, they can turn off the Sentry.init do |config|
# ...
config.backtrace_cleanup_callback = ->(x) { x }
end |
sl0thentr0py
changed the title
|
Ah, this all makes sense, we'd figured this functionality was tablestakes for a Sentry SDK, glad you already support it and thanks for the clarification on the backtrace path cleaner regression. We'll give this a shot and report back. |
|
fix is up at #2474, will probably take a week or so for review/release. |
In Rails 7.2, Rails's backtrace cleaner, which sentry-rails' backtrace cleaner inherits from, starts shortening gem's paths in backtraces. This will present sentry-ruby's `Sentry::Backtrace` from handling them correctly, which will result in issues like #2472. This commit avoids the issue by clearing the default filters that Sentry's backtrace cleaner inherits.
In Rails 7.2, Rails's backtrace cleaner, which sentry-rails' backtrace cleaner inherits from, starts shortening gem's paths in backtraces. This will prevent sentry-ruby's `Sentry::Backtrace` from handling them correctly, which will result in issues like #2472. This commit avoids the issue by clearing the default filters that Sentry's backtrace cleaner inherits.
In Rails 7.2, Rails's backtrace cleaner, which sentry-rails' backtrace cleaner inherits from, starts shortening gem's paths in backtraces. This will prevent sentry-ruby's `Sentry::Backtrace` from handling them correctly, which will result in issues like #2472. This commit avoids the issue by clearing the default filters that Sentry's backtrace cleaner inherits.
* Clear Rails' default backtrace filters from Sentry's backtrace cleaner In Rails 7.2, Rails's backtrace cleaner, which sentry-rails' backtrace cleaner inherits from, starts shortening gem's paths in backtraces. This will prevent sentry-ruby's `Sentry::Backtrace` from handling them correctly, which will result in issues like #2472. This commit avoids the issue by clearing the default filters that Sentry's backtrace cleaner inherits. * Remove premature path-removal filter This filter removes the project root part from the stacktrace, which prevents sentry-ruby from retaining the correct absolute path of it.
Describe the idea
Currently, the Ruby Sentry SDK provides stack traces that include the file name, line number, and method name where an error occurred. However, it does not include the actual lines of source code. This feature is crucial for debugging, especially when dealing with third-party code, as it provides immediate context around the error without requiring developers to manually locate and open the files.
The feature request is to add functionality to the Ruby Sentry SDK to extract and include source code snippets in stack traces. This can be achieved by implementing a mechanism similar to the CodeExtractor class in the Bugsnag SDK, which reads the relevant files and attaches the surrounding lines of code to the stack trace.
Why do you think it's beneficial to most of the users
Improved Debugging: Including source code snippets in stack traces allows developers to quickly understand the context of an error, making it easier to diagnose and fix issues.
Third-Party Code: When errors occur in third-party libraries, developers may not be familiar with the code. Providing the surrounding lines of code helps them understand what might be going wrong without needing to dive into the third-party codebase.
Efficiency: This feature saves time by reducing the need to manually locate and open files to see the relevant lines of code. It streamlines the debugging process and helps developers focus on solving the problem.
The text was updated successfully, but these errors were encountered: