Bug #21348
openShould Tracepoint track retry as another "call" event?
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) 6 months 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) 6 months ago
Thanks for confirming that the behavior needs to be fixed @Eregon (Benoit Daloze).
Updated by Eregon (Benoit Daloze) 6 months 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