Byebug can not step over Rails model create (latest Ruby/gems, incl repro instructions)

[wbharding]

Problem description

Using Rails 6.0.32, Ruby 2.7.1 and Byebug 11.1.3, I'm unable to step over the creation of a new Rails model. When byebug is on the step before a model is created and "next" is invoked, byebug will either treat the "next" like a "continue" (that is, it never stops after creating the model) or jump to an unrelated files in Rails. In the example case provided, where Rails parallelization has been disabled (if parellization is enabled, the execution stops within that), byebug jumps to

[364, 373] in /Users/bill/.rvm/gems/ruby-2.7.1@vanilla-rails/gems/minitest-5.14.1/lib/minitest.rb
   364:         action.call
   365:       end if supported
   366:
   367:       yield
   368:     ensure
=> 369:       trap name, old_trap if supported
   370:     end
   371:
   372:     ##
   373:     # Each subclass of Runnable is responsible for overriding this

Expected behavior

When invoking "n" on the line before model creation, the debugger should create the model and then stop running in the same context the user had been in when they entered "n", with the newly created model available to be inspected.

Actual behavior

Byebug gets snagged within minitest in the provided sample case. In our project, Byebug just doesn't stop at all when we enter "n" before a model is to be created.

Steps to reproduce the problem

I have set up a default Rails 6.0.32 repo that repros this problem here https://github.com/wbharding/vanilla-rails. To see the behavior in question, grab the repo, install its gems, run rails db:create, and then invoke the test

rails test test/models/blog_post_test.rb

When you get to the breakpoint, press "n" and observe that we're able to step over an assert. Then press "n" again and observe byebug getting stuck in minitest with the message shown above.

[wbharding]

fwiw @deivid-rodriguez I'm not sure how active you still are on this project, but our company is open to compensating you for any time to review/resolve this issue, since our team relies on byebug as a foundation of our debugging infrastructure. Drop me a line if interested.

[0x2c7]

@wbharding This maybe a consequence of this issue: #719.