ruby icon indicating copy to clipboard operation
ruby copied to clipboard

Debugging tests on remote

Open pprotas opened this issue 5 months ago • 1 comments

I'm debugging Rails/Sidekiq running on a Docker host using this configuration:

[
  {
    "label": "Debug Rails server",
    "adapter": "rdbg",
    "request": "attach",
    "env": {
      "RUBY_DEBUG_PORT": "12345"
    }
  },
  {
    "label": "Debug Sidekiq",
    "adapter": "rdbg",
    "request": "attach",
    "env": {
      "RUBY_DEBUG_PORT": "12346"
    }
  }
]

Rails/Sidekiq are executed using these commands in my docker-compose.yml:

command: "bundle exec rdbg --open --host=0.0.0.0 --port=12345 --nonstop --command -- bin/rails server -b 0.0.0.0 -p 3000"

So far so good. I am able to hit breakpoints in Zed.

Then I tried doing a similar thing for testing. Relevant test task in my tasks.json:

{
  "label": "test $ZED_RELATIVE_FILE:$ZED_ROW",
  "command": "bin/rspechelper",
  "args": ["\"$ZED_RELATIVE_FILE:$ZED_ROW\""],
  "tags": ["ruby-test"],
  "env": {
      "RUBY_DEBUG_PORT": "12344"
    }
},

And in my bin/rspechelper, which just passes the arguments to the Docker container:

docker compose exec rspec-container bundle exec rdbg --open --host=0.0.0.0 --port=12344 --command -- bin/rspec #{processed_args.join(' ')}

Then I try to debug the rspec test using the debug: test ..... option when clicking the launch arrow

In my Zed Adapter logs I only see this:

stderr: DEBUGGER: Debugger can attach via TCP/IP (0.0.0.0:12344)

stderr: DEBUGGER: wait for debugger connection...

My understanding of the situation:

  • RDBG is running in the Docker rspec container on port 12344
  • I can confirm that the port is forwarded and I can connect to it using rdbg --attach --port=12344 from my local machine
  • And yet, when I try to debug the rspec through Zed, it does not connect and the debugger is indefinitely waiting for a connection

I must be setting something incorrectly, any help?

pprotas avatar Sep 15 '25 14:09 pprotas

Hi, thanks for reporting. This scenario looks like an issue with converting (runnable) tasks into a DAP scenario here. I will try replicating your scenario, but a minimal reproduction would be helpful.

vitallium avatar Sep 20 '25 18:09 vitallium