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

Proper way of hooking methods named call #344

Open
ikuo opened this issue Oct 9, 2023 · 2 comments
Open

Proper way of hooking methods named call #344

ikuo opened this issue Oct 9, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@ikuo
Copy link

ikuo commented Oct 9, 2023

It looks that we globally ignore methods named call here.

When we want to hook methods named call in our application Ruby classes (./app or ./lib in our case), is there any proper way to do this?

Currently, I'm working around it with a monkey patch like this:

# lib/appmap/hook.rb
module AppMap
  class Hook
    def trace_end(...)
      ...
      local_path = location.delete_prefix(Dir.pwd + '/')
      is_app = local_path.start_with?('app') || local_path.start_with?('lib')
      next if !is_app && method_id == :call

But I think there must be a better way to do this.

@kgilpin
Copy link
Contributor

kgilpin commented Oct 10, 2023

Hi, great question. I believe this restriction is here because hooking methods named call can interfere with the recording process itself.

In AppMap configuration there is an explicit list of functions to be recorded:

https://appmap.io/docs/reference/appmap-ruby.html#configuration

Maybe functions listed here should not be subject to the call restriction? In that case it will be “caveat emptor” about possible interference.

We could also look at renaming internal call methods of AppMap to mitigate the need for this restriction.

@kgilpin kgilpin added the bug Something isn't working label Oct 10, 2023
@ikuo
Copy link
Author

ikuo commented Oct 11, 2023

@kgilpin Hi, thank you for letting me know the background and possible approaches.

I feel like the first approach (explicit list with caveat emptor) helps us a lot if it supports glob patterns based on source_location etc. since my app has a lot of call methods defined.
And with existing or new test programs, I hope we can mitigate the possible interference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants