search

getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
38.56k stars 4.12k forks source link

Ruby Stack Trace Missing Gem Folder Names in Sentry Reported Paths #77184

Open Kobby-Bawuah opened 1 week ago

Kobby-Bawuah commented 1 week ago

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

A user is reporting that Sentry is modifying Ruby stack traces by stripping out the gem folder names, making it difficult to trace errors back to their source. Specifically, when Sentry displays paths like active_record/connection_adapters/abstract_mysql_adapter.rb, it omits the gem folder name, which should be something like activerecord-5.2.4.1/. The user needs the full gem path preserved to navigate the stack trace in their IDE and identify the correct gem, as internal paths within gems can be ambiguous without the versioned folder name.

Expected Result

The stack trace paths should include the full gem folder names (e.g., activerecord-5.2.4.1/) so that users can easily navigate them within their IDEs.

Actual Result

Sentry is stripping the gem folder names from the paths, leaving only the internal paths within the gem (e.g., active_record/connection_adapters/abstract_mysql_adapter.rb). This makes it difficult to map these paths to the real gem files on the system.

Product Area

Processing

Link

No response

DSN

No response

Version

No response

getsantry[bot] commented 1 week ago

Routing to @getsentry/product-owners-processing for triage ⏲️

getsantry[bot] commented 1 week ago

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

alxwrk commented 1 week ago

https://github.com/getsentry/sentry-ruby/blob/c3bcfa0401856d9ee7616c95ab9dfe988a89da30/sentry-ruby/lib/sentry/interfaces/stacktrace.rb#L45-L58

The problem seems to there. Frame ends up with a good @abs_path and a bad @filename with the the ${GEM_FOLDER}/lib stripped out. I am guessing you upload both. So two improvements should be made:

  1. Since you already have access to the @abs_path you should have an option in your portal to toggle absolute paths in the raw stacktrace view. Perhaps absolute should be default for raw, because a truncated path is by definition not raw.
  2. The default computation of @filename should retain the gem folder because without it the path is too ambiguous. Its entirely possible to have identical filenames in different gems.
MichaelSun48 commented 6 days ago

This ticket appears to concern SDK and not Issues – I'll route it to them internally since they will have more context on this

alxwrk commented 6 days ago

There are two parts here which perhaps should be split.

  1. Avoiding the default stripping of the gem folder, that's an SDK issue.
  2. Exposing the absolute paths (which you're already collecting I believe) in the portal raw stacktraces.
alxwrk commented 5 days ago

There are two parts here which perhaps should be split.

  1. Avoiding the default stripping of the gem folder, that's an SDK issue.
  2. Exposing the absolute paths (which you're already collecting I believe) in the portal raw stacktraces.

Created a separate feature request for 2: #77320