Project

General

Profile

Actions

Bug #21348

open

Should Tracepoint track retry as another "call" event?

Added by karthikc (Karthik Chandrasekariah) 6 days ago. Updated 2 days ago.

Status:
Open
Assignee:
-
Target version:
-
ruby -v:
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux]
[ruby-core:122175]

Description

When retry is executed in a method, Tracepoint records it as a new "call" event.

# tracepoint-retry.rb

# method that retries once
def foo
  attempts ||= 1
  raise "Fail" if attempts == 1
rescue
  attempts += 1
  retry
end

trace = TracePoint.new(:call, :return) do |tp|
  p [tp.event, tp.method_id]
end

trace.enable
foo
$ ruby -v
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-darwin24]

$ ruby tracepoint-retry.rb
[:call, :foo]
[:call, :foo]
[:return, :foo]

It results in multiple "call" events and a single "return" event. Since the retry doesn't technically leave and re-enter the method, should we change Tracepoint to not fire the second "call" event?

Context - I am building a library that tracks everything that happened in a block of code. This behavior makes it look like foo was called within foo but the outer call never returned/completed.

Updated by Eregon (Benoit Daloze) 4 days ago

I agree with the OP that :call shouldn't trigger a second time here, since there is only one call to foo.
retry is similar to a loop, and of course we don't add extra :call TracePoint events for loops.

Updated by karthikc (Karthik Chandrasekariah) 2 days ago

Thanks for confirming that the behavior needs to be fixed @Eregon (Benoit Daloze).

Actions #3

Updated by Eregon (Benoit Daloze) 2 days ago

  • Tracker changed from Misc to Bug
  • ruby -v set to ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux]
  • Backport set to 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN
Actions

Also available in: Atom PDF

Like0
Like1Like0Like0