Repository navigation
Feature request: Stop debugger until first client connects #739
Description
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 connectsOnce 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.
Activity
st0012 commentedon Aug 31, 2022
In the use case you described, do you always have breakpoints set in your tests?
If the answer is yes, then using
debug/open_nonstopwill 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.
jvilk-stripe commentedon Aug 31, 2022
Yes -- in VS Code.
The problem is that the breakpoints get set just after VS Code attaches. VS Code is doing the breakpoint setting.
ko1 commentedon Sep 16, 2022
Hi, I understand your request that
Right?
Can I ask something?
#openmethod like ✨ Add on_client_connected to Session.open, to allow for synchronization #747Maybe (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.marianosimone commentedon Sep 20, 2022
@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 #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_mapmarianosimone commentedon Nov 2, 2022
@ko1 can you say more about:
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 :)
`"nonstop": true` option (default: false) on launch.json
ko1 commentedon Nov 3, 2022
#792 (comment) adding (b).
Could you check it?
`"nonstop": true` option (default: false) on launch.json
ko1 commentedon Nov 3, 2022
For (c) please try:
"(experimental) Save breakpoints information to '.rdbg.breakpoints' for rdbg command"optionrdbg -nOwith-x .rdbg.breakpointslikerdbg -x .rdbg.breakpoints -nO sample.rband it debuggee process will stop at the breakpoint and you can attach from VSCode.
Extension.Development.Host.sample.rb.-.simple_sample.WSL_.Ubuntu-20.04.-.Visual.Studio.Code.2022-11-04.06-25-42.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.