Server Mode

[dlanileonardo]

The PR enable a server-mode option with doesn't wait for connection to start webserver, it's very sux when you are working with microservices, start a docker container justo to debug. With this PR you can start rails and work, debugging when you want.

Is good to Docker an Vscode. 😉

[jamesmosier]

Anything I can do to get this PR merged in? @denofevil @mkrauskopf

[paulodeleo]

@dlanileonardo great addition, I'm using ruby-debug-ide from your repo until it gets merged.

By the way, what is your workflow for rails debugging with docker? I'm using restart: always with this ugly docker-compose command so when I disconnect from the debugger, killing the server, the container is restarted, getting rid of server.pid left by puma:

command: /bin/sh -c "rm -f /app/tmp/pids/server.pid && bundle exec rdebug-ide --server-mode --debug --host 0.0.0.0 --port 1234 -- bin/rails s -b 0.0.0.0"

[ViugiNick]

@paulodeleo https://www.jetbrains.com/help/ruby/remote-debugging.html You can run something like rdebug-ide --host 0.0.0.0 --port <port number> --dispatcher-port <port number> -- $COMMAND$ inside docker. And it will wait for connections to start your rails app.

[paulodeleo]

@ViugiNick that is what I'm already doing, and the whole point of this PR is to have a way to avoid making the server wait for a connection and be able to connect whenever you want, witch --server-mode option provides.

What I would also like to do is to be able to freely disconnect / reconnect the debugger without killing the server process. Much like the pry way of debugging workflow: when you need a breakpoint / REPL, just put a binding.pry line on any .rb file, save it, and the already running rails server will detect the breakpoint on the next page reload. Remove the call to binding.pry and it is gone. No need to restart the development rails server process with a special command line before of after needing to debug.

As I recently switched to VS Code and discovered ruby-debug-ide I don't know if such convenient way of debugging ruby is possible or if I'm missing something.

[dlanileonardo]

Hi @paulodeleo, I'm Using the branch feature/debugger of my fork vscode-ruby, because the repository owner vscode-ruby did not accepeted my request, anyway how can you observed the both don't accept my PR, so i think devs are too pround 😡, because that way the Workflow of the dev would look perfect as it should be.

In this branch, the debugger works exactly as u need it.

Just put feature/debugger branch in ~/.vscode/extensions

# my launcher.json
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen Local Debug",
      "type": "RubyDebugger",
      "request": "attach",
      "cwd": "${workspaceRoot}",
      "remoteHost": "127.0.0.1",
      "remotePort": "1231",
      "remoteWorkspaceRoot": "/app",
      "useBundler": true,
      "showDebuggerOutput": true
    }
  ]
}

My extension to Debug like a Boss 😎 and vscode-ruby 🤐 official to write code and lint.

Sorry for delay. 🙏🏻

[paulodeleo]

@dlanileonardo I'm getting this error when trying to start debugging with "type": "RubyDebugger" setting on launch.json:

Debug adapter process has terminated unexpectedly (read error).

Any idea of what is wrong?

[Eusebius1920]

Any news on this? What are the blockers preventing this from getting merged?

[ViugiNick]

@dlanileonardo @jamesmosier @paulodeleo @Eusebius1920 I don't fully understand what the difference between this approach and just disabling all breakpoints, keeping the debug session running. I'd like to note that if you initially launched the application with debugging, ruby virtual machine handlers will be installed for it(here https://github.com/ruby-debug/ruby-debug-ide/blob/235f8fa86b23295f23b4f7894b2ec3418da73e3e/lib/ruby-debug-ide.rb#L100), which will significantly hit the overhead. And it doesn't matter if the socket is connected or not. So as for me it's better to use mute breakpoints functionality.

[Eusebius1920]

@ViugiNick I am using ruby-debug-ide with visual studio code and there your abilities and hotkeys change if there is an active deugging session (to better suit your needs in such situations).

So I prefer having my debug-session running (always) and just attaching to the debugger (with visual-studio-code) if I really want to debug somewhere. If I start the ruby-debug-ide then I have to attach to it quickly and disconnect everytime to get the ruby-application up and running (so that I can re-attach later, when I need it). Otherwise ruby-debug-ide will just wait for a first connect and the ruby-application never gets started.

This is kind of annoying, that you have to attach just as a formality each time you start the debugger. Always running in debug-mode in visual studio code is not ideal either as it switches on purpose to the mentioned debug-mode when you connect to a debugger.

In the current setting I have two realistic settings:

• Startup debugger only if I need it and run the ruby application without debugger if I dont need it.
• Quickly connect each time I start the application only so that ruby-debug-ide spins up the application.

[Eusebius1920]

I guess this wants to achieve exactly the same: https://github.com/ruby-debug/ruby-debug-ide/pull/167

[jamesmosier]

My use case is this: As a team we have a rails server running in Docker and not everyone uses vscode and not everyone wants to run ruby-debug. Therefore I wanted to have opt-in functionality for those of us who want to start up the rails server via docker, connect/disconnect the debugger, or not run it at all.

Either way not a huge deal, I understand the limitations/hesitations with this and my closed PR.

Thanks for your work on the extension!

[ViugiNick]

@jamesmosier But after all, in order to connect to the debug server, you still need to initially run the debug command, and not just the rails server. In other words, your command line will be different from a command line of people who are not going to debug the application.

Maybe you need something like that https://www.jetbrains.com/help/ruby/attaching-to-process.html or like that https://blog.jetbrains.com/ruby/2018/05/rubymine-2018-2-eap-is-open/#attach_to_remote_processes

[dlanileonardo]

@ViugiNick When use Docker and Compose to development, and you have micro services with a lot of dependency's, restarting and alternate Instance Work and Instance Debug is a waste of time. With this PR, you server just run and you can use application debugging or not, the server listening debug port and you can attach it in anytime.

Example:

docker-compose.yml

mysql: ...

frontend: ...
  depends_on:
    - api
    - backend
    - cable

api:
  depends_on:
    - mysql
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/api.pid -p 3000 -b 0.0.0.0

sidekiq:
  depends_on:
    - cable
    - mysql
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/sidekiq.pid -p 3000 -b 0.0.0.0

cable:
  - api
  ...
  command: bundle exec bundle exec rdebug-ide --evaluation-timeout 10 --server-mode --host 0.0.0.0 --port 1231 -- bin/rails s -P /app/tmp/pids/cable.pid -p 3000 -b 0.0.0.0

In this example, today (without server mode) i needed change my docker-compose.yml for every debug or work instance in cable, sidekiq or api , this cause a restart of frontend unnecessarily.

[ViugiNick]

@dlanileonardo Why can't you just mute breakpoints and use the same docker-compose.yml?

[ViugiNick]

@dlanileonardo With such technique you can switch back to debugging just by unmuting them without reconnecting to debug session (as I mentioned here https://github.com/ruby-debug/ruby-debug-ide/pull/145#issuecomment-481380449)

[dlanileonardo]

@dlanileonardo Why can't you just mute breakpoints and use the same docker-compose.yml?

@ViugiNick The problem is I need to connect every instance to this work, and open 3 windows vscode and connect it in cable, sidekiq and api.

[Eusebius1920]

I guess the whole Pullrequest essentially boils down to this single line of code (or even only the the second half): https://github.com/ruby-debug/ruby-debug-ide/blob/57f4243060d8b4e5b892be55f2a429138d579e4b/lib/ruby-debug-ide.rb#L103 (Can you confirm this @dlanileonardo ?)

Is this adding so much complexity that it can become a burder that you have to drag along in further development (This is not meant to sound sarcastic but a serious question to those who know the internals of this project. I have no idea who this project internally works in any detail)

If not the discussion appears really unnecessary to me.

I am not happy with the naming (server_mode) or the description of the flag ("Tells that rdebug-ide is working in server mode"). I would it call no_wait or something like that.

[ViugiNick]

@dlanileonardo There are some unresolved comments in review.

[iggycoder]

Could we please just merge this now? Just as a side note...it's just a flag/option. Nobody is forced to use it. I also don't understand this discussion. I have a hard time understanding the current short comings though. I want to connect or disconnect to a debug server session without

• starting/initializing the server only when I am connecting to the debug process the first time. Why coupling that behavior?
• killing the server process when disconnecting

This is especially annoying in multi-server local dev setups with docker-compose.

I hope there's a way to have this PR merged.

[ViugiNick]

@iggycoder As you can see, there are a number of comments for this PR, thats why we don't merge it for now.

[iggycoder]

@ViugiNick Overlooked that. sorry. @dlanileonardo Any chance to comment and/or change based on the review? I’d love to see that feature merged.