dejan/rails_panel

Active Record Location is referencing Gem files instead of project code

klueless-io opened this issue · 3 comments

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

image

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

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)\//);
    }
  })

Could we have a new version to fix this?