vscode-ruby version: 0.24.1useLanguageServer is true?) NoVersions of possibly relevant gems (though updating didn't help in this case):
ruby-debug-ide version (0.6.0)
debase (0.2.3)
debase-ruby_core_source (0.10.5)
After adding a breakpoint and disabling it, starting the debugger should work as normal, ignoring the disabled breakpoints.
Leaving any disabled breakpoints in prevents the debugger from (properly?) starting. Nothing is written to the debug console, and in the case of the Rails server it does not respond to requests. However, the draggable debug toolbar does appear which responds to stop/restart and trying to launch twice gives the usual error message There is already a debug configuration <config name> running.
Enabling or removing the breakpoints and restarting allows the launch configurations to work as normal.
I've observed this behaviour with a Rails project (using the default configuration for launching rails servers) and a plain Ruby project (using the configuration listed here: https://github.com/rubyide/vscode-ruby/wiki/2.-Launching-from-VS-Code).
Obviously there's an easy workaround here, but it took a while to figure out this was the issue so it would be useful to have some kind of warning if a fix isn't feasible.
I have the same issue with a rack server. With logging enabled, the only message printed is Fast Debugger (ruby-debug-ide 0.7.0, debase 0.2.2, file filtering is supported) listens on 127.0.0.1:1234 and puma never launches.
Same problem here. I just wanted to mention that launching with disabled breakpoints used to work, but I don't know exactly when it stopped.
Yep, same problem here.
Problem still exists, extension 0.25.3, OSS code v 1.39.2, electron 4.2.12
This issue has not had activity for 30 days. It will be automatically closed in 7 days.
Still seeing this issue with debase 0.2.4.1, ruby-debug-ide 0.7.2, Ruby 2.7.1 and vscode-ruby 0.27.0.
This issue has not had activity for 30 days. It will be automatically closed in 7 days.
Planning on verifying once have time, to make sure this issue isn't closed inappropriately...
I'm definitely able to reproduce this issue locally with VS code.
I've filed an issue with them which is similar, but slightly different. (issue: https://github.com/rubyide/vscode-ruby/issues/657)
In the case of the issue I've filed, it seems that ruby-debug-ide is closing and re-opening the connection to vscode over and over (tcp handshake -> [FIN ACK] is sent, another tcp handshake, etc)
In this case, though, I don't see that happening locally. Here's a screenshot of wireshark as I run rdebug-ide and connect with vscode while there is a single breakpoint that's disabled.

Here's a screenshot of the same thing, but with that breakpoint enabled. Notice that the highlighted packed contains the word start, which causes ruby-debug-ide to start the executable it's been given.

What's important here, though, is that VS code is not sending the start command when all breakpoints are disabled.
This issue has not had activity for 30 days. It will be automatically closed in 7 days.
Still seeing this:
0.27.0ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-darwin19]rbenvVersion: 1.50.110.15.7debase (0.2.4.1)ruby-debug-ide (0.7.2)solargraph (0.39.17)I am seeing this also, but noticed if sending SIGINT to the process it will no longer wait to launch.
Most helpful comment
I have the same issue with a rack server. With logging enabled, the only message printed is
Fast Debugger (ruby-debug-ide 0.7.0, debase 0.2.2, file filtering is supported) listens on 127.0.0.1:1234and puma never launches.