Launching with the debugger does not work if there are disabled breakpoints

[AlexMunro]

Your environment

• vscode-ruby version: 0.24.1
• Ruby version: 2.6.3p62
• Ruby version manager (if any): asdf
• VS Code version: 1.36.1
• Operating System: MacOS Mojave 10.14.5
• Using language server? (eg useLanguageServer is true?) No

Versions 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)

Expected behavior

After adding a breakpoint and disabling it, starting the debugger should work as normal, ignoring the disabled breakpoints.

Actual behavior

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.

[griest024]

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.

[castwide]

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.

[iggycoder]

Yep, same problem here.

[whitehorsesoft]

Problem still exists, extension 0.25.3, OSS code v 1.39.2, electron 4.2.12

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[AlexMunro]

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.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[whitehorsesoft]

Planning on verifying once have time, to make sure this issue isn't closed inappropriately...

[lalunamel]

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: #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.

[github-actions]

This issue has not had activity for 30 days. It will be automatically closed in 7 days.

[brahn]

Still seeing this:

• vscode-ruby version: 0.27.0
• Ruby version: ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-darwin19]
• Ruby version manager (if any): rbenv
• VS Code version: Version: 1.50.1
• Operating System: MacOS Catalina 10.15.7
• Gems of interest:
  • debase (0.2.4.1)
  • ruby-debug-ide (0.7.2)
  • solargraph (0.39.17)

[carsonreinke]

I am seeing this also, but noticed if sending SIGINT to the process it will no longer wait to launch.