VS Code breakpoints skipped after Rails reloads related code

[st0012]

Your environment

• ruby -v: 3.1.2
• rdbg -v: 1.7.0

Describe the bug

Breakpoints added via VS Code seems to be lost after surrounding code is modified and reloaded by Rails.

For example, if we set a breakpoint at

def index
  @posts = Post.all # set the breakpoint at this line
end

And then we insert a new line to the method:

def index
  puts "foo"
  @posts = Post.all # VS Code would move the breakpoint here after update
end

The breakpoint would not be triggered anymore.

To Reproduce

1. Clone this repo.

2. Run $ bundle install.

3. Run $ bundle exec bin/rails db:migrate RAILS_ENV=development.

4. Run $ bundle exec rdbg -O -n -c -- bundle exec bin/rails s to run the server with debugger in server mode.

5. Press F5 to attach VS Code to the debugger.

6. Go to app/controllers/posts_controller.rb and place an VS Code breakpoint at line 6.

   def index
     @posts = Post.all # set the breakpoint at this line
   end

7. Verify the breakpoint can be hit:

   1. In browser, visit http://localhost:3000.
   2. See the breakpoint being hit.
   3. Press F5 again to continue the program.

8. Add puts "foo" at app/controllers/posts_controller.rb:6

   def index
     puts "foo"
     @posts = Post.all
   end

9. Refresh the page in browser.

Expected behavior

VS Code breakpoints can still trigger after the file is updated.

Additional context

• When updating other methods, like adding something to the new method (10 lines away), the breakpoint still works. So I suspect it's related to the breakpoint's iseq being outdated?

• From DAP server logs, it looks like the debugger does receive updated setBreakpoints request:

#25986:[>] {"command":"setBreakpoints","arguments":{"source":{"path":"/Users/hung-wulo/src/github.com/st0012/debug-issue/app/controllers/posts_controller.rb","name":"posts_controller.rb","sourceReference":0},"lines":[6],"breakpoints":[{"line":6}],"sourceModified":true},"type":"request","seq":13}
#25986:[<] {"type":"response","command":"setBreakpoints","request_seq":13,"success":true,"message":"Success","body":{"breakpoints":[{"verified":true}]},"seq":977}

But the breakpoint wasn't actually added/activated.

[st0012]

I think it's related to LineBreakpoint's @pending state:

After the first breakpoint hit, the later breakpoint would has @iseq like

<RubyVM::InstructionSequence:index@/Users/hung-wulo/src/github.com/st0012/debug-issue/app/controllers/posts_controller.rb:5>

And this means its @pending state would be false.

So when the :script_compiled event is triggered

1. bps_pending_until_load? would also be false
2. Thus ThreadClient.current.on_load wouldn't be triggered for the updated code
3. Which could have reloaded related LineBreakpoints

But I'm not sure which part is the root cause of the issue:

• Should the later breakpoint's @iseq still be nil?
• Should bps_pending_until_load? also take the bps' file path into consideration?
• Or it could be something else?

Workaround

As a quick workaround, changing bps_pending_until_load? to just do @bps.any? seems to work.

[crobbo]

Nothing to add other than to comment I have also been experiencing this bug. For the breakpoints to start registering after changing the code I have restart the server and attach the debug session again.

A fix for this would be great!

[ko1]

# repro code
File.write("l.rb", <<RUBY)
  # l.rb
  def foo # 2
    p 1   # 3
    p 2
  end
RUBY
load 'l.rb'
foo

debugger do: 'b l.rb:3'

p :loeaded

File.write("l.rb", <<RUBY)
  # l.rb
  def foo
    p 0
    p 1
    p 2
  end
RUBY

load 'l.rb'

foo

[ko1]

Sorry it is not a correct repro-code.
It needs VSCode interaction.

[ko1]

All right, I repro it.

File.write("l.rb", <<RUBY)
  # l.rb
  def foo
    p 1
  end
RUBY

load 'l.rb'
p :loeaded
debugger # set braekpoint at "l.rb:3" here

File.write("l.rb", <<RUBY)
  def foo
    p 0
    p 1
  end
RUBY

load 'l.rb'

foo

and next foo doesn't stop.

[ko1]

File.write("l.rb", <<RUBY)
  def foo
    p 1
  end
RUBY

load 'l.rb'
p :loeaded

debugger do: 'b l.rb:2'

foo

File.write("l.rb", <<RUBY)
  def foo
    p 0
    p 1
  end
RUBY

load 'l.rb'

foo

This is repro-code.