Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Active Record Location is referencing Gem files instead of project code #171

Open
klueless-io opened this issue Nov 13, 2019 · 3 comments
Open

Comments

@klueless-io
Copy link

klueless-io commented Nov 13, 2019

Active record location is referencing Gem files instead of project code in the chrome debugger

image

@0xdevalias
Copy link

It looks like the following is responsible for this logic:

caller contains an array of 'stacktrace' paths, eg:

=> ["/Users/REDACTED/dev/REDACTED/vendor/bundle/ruby/2.4.0/gems/meta_request-0.7.2/lib/meta_request/app_notifications.rb:81:in `block in subscribe'",
 "/Users/REDACTED/dev/REDACTED/vendor/bundle/ruby/2.4.0/gems/activesupport-5.2.3/lib/active_support/notifications/fanout.rb:129:in `finish'",
 "/Users/REDACTED/dev/REDACTED/vendor/bundle/ruby/2.4.0/gems/activesupport-5.2.3/lib/active_support/notifications/fanout.rb:48:in `block in finish'",

..snip..

I'm not really sure of the intent of this code and how it flows through to other areas within the application to know if/how to modify it though.

The following helper could also potentially be changed to shorten the rails root 'prefix' from these paths, to make them a bit shorter

@0xdevalias
Copy link

0xdevalias commented Nov 13, 2019

By changing this line to the following, you can skip past all the bundled vendor dependencies and likely land in the most relevant 'last point of call' within your application code itself:

app_line = caller.detect { |c| c.start_with?(MetaRequest.rails_root) && !c.include?(File.join(MetaRequest.rails_root, 'vendor')) }

That ends up looking something like this:
image

Which is obviously a lot better, but not perfect, as we still have full file paths for some of those entries.. which seems to be handled by normalizePath in the chrome extension code:

I believe if it was modified to something like this, it should better handle those paths as well:

  filter('normalizePath', function() {
    return function(input) {
-      return input.remove(/.*\/app\//);
+      return input.remove(/.*\/(app|config|lib|fooMaybeOtherStuffHere)\//);
    }
  })

@bingxie
Copy link

bingxie commented Jun 17, 2020

Could we have a new version to fix this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants