Issue #21348 has been updated by Eregon (Benoit Daloze). 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. ---------------------------------------- Misc #21348: Should Tracepoint track retry as another "call" event? https://bugs.ruby-lang.org/issues/21348#change-113349 * Author: karthikc (Karthik Chandrasekariah) * Status: Open ---------------------------------------- When `retry` is executed in a method, Tracepoint records it as a new "call" event. ``` ruby # 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 ``` ``` shell $ 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. -- https://bugs.ruby-lang.org/