Feature request: Stop debugger until first client connects
Your proposal
Make it possible for the debugger to pause the program until the first client connects:
require "debug/open_wait_for_client"
# Program is now paused until the first debugger client connects
Once the first client connects, the program can proceed.
Additional context
We are working to integrate debug.rb into Stripe's Ruby test runner. The test runner needs to start the server and wait for VS Code to connect before running the tests.
debug/open does not work for this use case. debug/open pauses the program when the debugger starts, but does not resume the program after VS Code connects. Instead, VS Code reports the program as paused on a breakpoint in our test runner code. The user then has to hit "resume" to run their tests and hit the breakpoints that they actually set.
In the use case you described, do you always have breakpoints set in your tests?
If the answer is yes, then using debug/open_nonstop will skip the initial stop, but will wait for attaching once it hits a breakpoint.
If the answer is no, then I don't get the need to connect to the VSCode since the program will just finish.
In the use case you described, do you always have breakpoints set in your tests?
Yes -- in VS Code.
If the answer is yes, then using debug/open_nonstop will skip the initial stop, but will wait for attaching once it hits a breakpoint.
The problem is that the breakpoints get set just after VS Code attaches. VS Code is doing the breakpoint setting.
Hi, I understand your request that
- On the VSCode, you setup breakpoints on the editor. You want to stop on that.
- You don't want to launch tests from VSCode (F5 key to launch debug process) maybe because there are some reasons.
- You want to invoke your test runner in your terminal or somewhere you want.
- You want to attach VScode just before your tests run.
- You don't want to stop the program at attaching timing, but you want to stop at breakpoints you setup on VSCode.
Right?
Can I ask something?
- There are some options to solve this issue.
-
- add an option to
#openmethod like #747
- add an option to
-
- add an option to VSCode launch.json (nonstop on attach)
-
- add an option to load breakpoints setup by VSCode on loading timing of debug.gem
-
Maybe (c) is most easy way for you because you don't need to launch VSCode and attach to the debuggee if no breakpoints are reached. When it stops at breakpoint, you can attach to the debuggee (test process) at that time.
In fact, vscode-rdbg supports to export breakpoints.

But not supported by debug.gem to load it because of some security concerns.
I want to ask which is the best. Honestly speaking on_client_connected: option (1) is too tricky for me.
@ko1: yes, your description of our requirements is correct. Also, I agree that my proposed solution is hacky, and doesn't follow any of the patterns that the debug gem already uses, so I'd be happy to see another solution.
Regarding your options:
a. is https://github.com/ruby/debug/pull/747 (which we agree is not the best)
b. I don't understand how this would be implemented on the gem, exactly
c. I assume you mean that users would set a new ENV variable/send a new option when starting the debugger, so the gem would know to try to load the breakpoints on startup. This looks like the most elegant solution, as long as it respects things like local_fs_map
@ko1 can you say more about:
But not supported by debug.gem to load it because of some security concerns.
This issue is the last thing that is preventing Stripe from using the gem without forking it, and we'd love to help move the feature along :)
https://github.com/ruby/debug/pull/792#issuecomment-1302536659 adding (b). Could you check it?
For (c) please try:
- enable
"(experimental) Save breakpoints information to '.rdbg.breakpoints' for rdbg command"option - set breakpoints on VSCode
- run
rdbg -nOwith-x .rdbg.breakpointslikerdbg -x .rdbg.breakpoints -nO sample.rb
and it debuggee process will stop at the breakpoint and you can attach from VSCode.
https://user-images.githubusercontent.com/9558/199837938-2ae9d8de-de45-47c8-a409-9d60ecb6a0c1.mp4
Now VSCode extension has an issue (breakpoint line is wrong with -1 because of 0-origin and 1-origin issue) but it will be fixed soon.