Launching rspec process via spring does not attach debugging as expected

[CJBridges]

spring, at an overly simplistic level, allows for early preloading of code, with the largest leverage tending to be gems. It functions by starting a process (spring server), then each time you want to run a command, it forks and the child process runs your main action (e.g. rspec).

rdebug-ide -- bin/rspec spec/file_spec.rb debugs the spring process, but does not debug the actual thing we want (the rspec child process launched underneath).

Steps to reproduce:

Case 1 (not working):

# bin/rspec
begin
  load File.expand_path('../spring', __FILE__)
rescue LoadError => e
  raise unless e.message.include?('spring')
end

require 'bundler/setup'

load Gem.bin_path('rspec-core', 'rspec')

rdebug-ide --host 127.0.0.1 --port 2345 -- bin/rspec spec/file_spec.rb

nc 127.0.0.1 2345 then...

break spec/file_spec.rb:5
cont

Expected: Break at line 5
Current: does not break at all

Case 2 (works, but slow):

DISABLE_SPRING=1 rdebug-ide --host 127.0.0.1 --port 2345 -- bin/rspec spec/file_spec.rb
(other steps same as above)

This breaks at line 5 as expected, but as spring is not used, we incur the whole cost of launching the app. This is > 10 seconds longer on an app I'm using it on.

---

In GDB, this is supported as set follow-fork-mode child - http://visualgdb.com/gdbreference/commands/set_follow-fork-mode.

Please let me know of any suggested fixes or workarounds, and I might be able to tackle it.

Other info: Note that my intended use case at the end of the day is to start an rspec process under debugger from vscode, with the launch speed benefits of spring, so vscode specific workarounds are fine too. I'm also familiar with other methods of debugging (e.g. binding.pry and byebug), but really trying to get first class IDE debugging support working.

[CJBridges]

Note that this behavior (not using spring while debugging) is also matched by RubyMine here (see "Special Notes" section).

[ViugiNick]

@CJBridges all forks are debuggable, as you can see here

ruby-debug-ide/lib/ruby-debug-ide/multiprocess/monkey.rb

Line 8 in b4c8f15

def fork(*args)

[ViugiNick]

@CJBridges What ruby/gems versions do you use?

[CJBridges]

@ViugiNick - I've been using:

Ruby 2.3.5
ruby-debug-ide (0.6.1)
spring (2.0.2)
spring-commands-rspec (1.0.4)

On a personal note, I've mostly moved away from using VSCode on a day to day, so I'm not going to be spending much additional time to help out with further debugging unfortunately beyond my repro above.

[bartocc]

@ViugiNick I've hit this issue after trying to debug my tests in my rails app.

I confirm that running with DISABLE_SPRING=1 hits breakpoints but running with spring does not hit breakpoints.

I can setup a demo repo is needed

[ViugiNick]

@bartocc What command do you run to debug tests?

[bartocc]

Running my tests with DISABLE_SPRING=1 rdebug-ide -x -- bin/rails test hits the breakpoints

Running my tests with rdebug-ide -x -- bin/rails test does not hit the breakpoints

[qortex]

I hit a related issue that I can't seem to solve.
Described here: rubyide/vscode-ruby#426

I understand it might be related: the debugger might attach to the Puma process instead of the thread where the actual controller code is run. Does it make sense? Is there a way to force proper behaviour?

I don't know if it's an issue in the VSCode extension or ruby-debug-ide.

[lopesrb]

I have the same problem.
@CJBridges @bartocc were you able to overcome this?

[ndbroadbent]

Sorry to comment on an old issue, but I really want to find a solution for this. I'm using an awesome VS Code extension called Test Explorer, with the Ruby test adapter. This makes VS Code feel like a proper IDE since it shows all my RSpec tests inside VS Code, and it has buttons and keyboard shortcuts I can use to start running or debugging tests.

So it would be awesome if I could get Spring working! This makes my tests so much faster, and I have to keep using the terminal until I can figure this out.

I don't have the time to keep digging into this, so I would be interested in sponsoring this issue using a third-party bounty service, maybe https://gitpay.me