"Debugger exited with status 1" for request=launch even though I'm able to execute the same command myself and then debug with request=attach

[Nowaker]

Operating System

Linux

Ruby version

3.3.0 / 3.1.4

Project has a bundle

• Has bundle

Ruby version manager being used

rvm

Description

    {
      "name": "Rails",
      "type": "ruby_lsp",
      "request": "launch",
      "program": "puma",
      "env": {
        "RAILS_DEBUG": "true"
      },
    }

Debugger exited with status 1. Check the output channel for more information.

2024-01-22 20:32:40.983 [info] (worldmodern) Checking if asdf is available on the path with command: /usr/bin/zsh -i -c 'asdf --version'
2024-01-22 20:32:41.353 [info] (worldmodern) Checking if chruby is available on the path with command: /usr/bin/zsh -i -c 'chruby --version'
2024-01-22 20:32:41.513 [info] (worldmodern) Checking if rbenv is available on the path with command: /usr/bin/zsh -i -c 'rbenv --version'
2024-01-22 20:32:41.673 [info] (worldmodern) Checking if rvm is available on the path with command: /usr/bin/zsh -i -c 'rvm --version'
2024-01-22 20:32:41.885 [info] (worldmodern) Discovered version manager rvm
2024-01-22 20:32:41.885 [info] (worldmodern) Trying to activate Ruby environment with command: /usr/bin/zsh -i -c 'rvm-auto-ruby -rjson -e "STDERR.printf(%{RUBY_ENV_ACTIVATE%sRUBY_ENV_ACTIVATE}, JSON.dump({ env: ENV.to_h, ruby_version: RUBY_VERSION, yjit: defined?(RubyVM::YJIT) }))"' inside directory: /home/nowaker/projekty/modern/worldmodern
2024-01-22 20:32:42.978 [info] (worldmodern) Starting Ruby LSP v0.13.1...

2024-01-22 20:32:43.150 [info] (worldmodern) Rails server is not running. To get Rails features in the editor, boot the Rails server
Ruby LSP is ready

2024-01-22 20:33:18.537 [info] Spawning debugger in directory /home/nowaker/projekty/modern/worldmodern
2024-01-22 20:33:18.537 [info]    Command bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-worldmodern-0.sock -- puma
2024-01-22 20:33:18.537 [info]    Environment {"RAILS_DEBUG":"true","SHELL":"/usr/bin/zsh","SESSION_MANAGER":"local/nwkr-desktop:@/tmp/.ICE-unix/1681,unix/nwkr-desktop:/tmp/.ICE-unix/1681","WINDOWID":"109051917","COLORTERM":"truecolor","VIRSH_DEFAULT_CONNECT_URI":"qemu:///system","rvm_delete_flag":"0","LDRAWDIR":"/usr/share/ldraw","GNOME_DESKTOP_SESSION_ID":"this-is-deprecated","APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL":"true","rvm_prefix":"/home/nowaker","LESS_TERMCAP_se":"\u001b[0m","LESS_TERMCAP_so":"\u001b[01;44;33m","LC_ADDRESS":"en_US.UTF-8","LC_NAME":"en_US.UTF-8","SSH_AUTH_SOCK":"/run/user/1000/keyring/ssh","CLOJURE_HOME":"/usr/share/clojure","SHELL_SESSION_ID":"a7310ab4de664398a9776b43c9fabdac","ELECTRON_RUN_AS_NODE":"1","MY_RUBY_HOME":"/home/nowaker/.rvm/rubies/ruby-3.3.0","LC_MONETARY":"en_US.UTF-8","NO_AT_BRIDGE":"1","VSCODE_AMD_ENTRYPOINT":"vs/workbench/api/node/extensionHostProcess","CLOUDSDK_PYTHON_ARGS":"-S","EDITOR":"vim","RUBY_VERSION":"ruby-3.3.0","XDG_SEAT":"seat0","PWD":"/home/nowaker/projekty/modern/worldmodern","LOGNAME":"nowaker","QT_QPA_PLATFORMTHEME":"qt5ct","XDG_SESSION_TYPE":"x11","rvm_version":"1.29.12-next (master)","RADV_PERFTEST":"aco","VSCODE_CODE_CACHE_PATH":"/home/nowaker/.config/Code/CachedData/8b3775030ed1a69b13e4f4c628c612102e30a681","XAUTHORITY":"/home/nowaker/.Xauthority","TF_PLUGIN_CACHE_DIR":"/home/nowaker/.terraform.d/plugin-cache","BUNDLER_ARGS":"-j30","MOTD_SHOWN":"pam","HOME":"/home/nowaker","LANG":"en_US.UTF-8","LC_PAPER":"en_US.UTF-8","LS_COLORS":"rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:","XDG_CURRENT_DESKTOP":"X-Cinnamon","KONSOLE_DBUS_SERVICE":":1.104","HOMEBREW_NO_ENV_HINTS":"1","VSCODE_IPC_HOOK":"/run/user/1000/vscode-04b39de9-1.85-main.sock","CLOUDSDK_ROOT_DIR":"/opt/google-cloud-cli","KONSOLE_DBUS_SESSION":"/Sessions/9","VSCODE_CLI":"1","gopath":"/home/nowaker/projects/go","KONSOLE_VERSION":"230804","CHROME_DESKTOP":"code-url-handler.desktop","CLOUDSDK_PYTHON":"/usr/bin/python","rvm_bin_path":"/home/nowaker/.rvm/bin","GEM_PATH":"/home/nowaker/.rvm/gems/ruby-3.3.0:/home/nowaker/.rvm/gems/ruby-3.3.0@global","GEM_HOME":"/home/nowaker/.rvm/gems/ruby-3.3.0","XDG_SESSION_CLASS":"greeter","HOMEBREW_NO_ANALYTICS":"1","LC_IDENTIFICATION":"en_US.UTF-8","TERM":"xterm-256color","LESS_TERMCAP_mb":"\u001b[01;31m","LESS_TERMCAP_me":"\u001b[0m","LESS_TERMCAP_md":"\u001b[01;31m","LIBVIRT_DEFAULT_URI":"qemu:///system","GOOGLE_CLOUD_SDK_HOME":"/opt/google-cloud-cli","USER":"nowaker","SDL_AUDIODRIVER":"pulse","PYTHON":"/usr/bin/python","COLORFGBG":"15;0","DISPLAY":":0.0","VSCODE_PID":"161766","LESS_TERMCAP_ue":"\u001b[0m","SHLVL":"2","LESS_TERMCAP_us":"\u001b[01;32m","PAGER":"less","LC_TELEPHONE":"en_US.UTF-8","CVS_RSH":"ssh","LC_MEASUREMENT":"en_US.UTF-8","VSCODE_CWD":"/home/nowaker/projekty/modern/worldmodern","XDG_VTNR":"7","DESKTOP_AUTOSTART_ID":"10ae9e882d65f9acbb170594272665819400000016810008","XDG_SESSION_ID":"1","rvm_ruby_string":"ruby-3.3.0","MOZ_PLUGIN_PATH":"/usr/lib/mozilla/plugins","LC_CTYPE":"en_US.UTF-8","VSCODE_CRASH_REPORTER_PROCESS_TYPE":"extensionHost","XDG_RUNTIME_DIR":"/run/user/1000","IDN_DISABLE":"0","DEBUGINFOD_URLS":"https://debuginfod.archlinux.org ","LC_TIME":"en_US.UTF-8","ELECTRON_NO_ATTACH_CONSOLE":"1","XDG_DATA_DIRS":"/home/nowaker/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share","GDK_BACKEND":"x11","PATH":"/home/nowaker/.rvm/gems/ruby-3.3.0/bin:/home/nowaker/.rvm/gems/ruby-3.3.0@global/bin:/home/nowaker/.rvm/rubies/ruby-3.3.0/bin:/home/nowaker/.rvm/bin:/home/nowaker/projects/dreamhost/kubekick:/home/nowaker/.local/bin:/home/nowaker/bin:/home/nowaker/.local/bin:/opt/google-cloud-cli/bin:/bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/opt/kde/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl","ORIGINAL_XDG_CURRENT_DESKTOP":"X-Cinnamon","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1000/bus","VSCODE_NLS_CONFIG":"{\"locale\":\"en-us\",\"osLocale\":\"en-us\",\"availableLanguages\":{},\"_languagePackSupport\":true}","HG":"/usr/bin/hg","MAIL":"/var/mail/nowaker","IRBRC":"/home/nowaker/.rvm/rubies/ruby-3.3.0/.irbrc","GIO_LAUNCHED_DESKTOP_FILE_PID":"4086","GIO_LAUNCHED_DESKTOP_FILE":"/home/nowaker/.config/autostart/yakuake.desktop","VSCODE_HANDLES_UNCAUGHT_ERRORS":"true","rvm_path":"/home/nowaker/.rvm","LC_NUMERIC":"en_US.UTF-8","OLDPWD":"/home/nowaker/projekty/modern/worldmodern","GOPATH":"/home/nowaker/projects/go","TF_CLI_ARGS_backup":"-","BUNDLE_GEMFILE":"/home/nowaker/projekty/modern/worldmodern/.ruby-lsp/Gemfile"}

Executing the exact same command from the log bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-worldmodern-0.sock -- puma succeeds. And I can attach a debugger from there with no issue, so something isn't adding up.

    {
      "name": "Rails (attach)",
      "type": "ruby_lsp",
      "request": "attach",
    }

I tried bumping the dependencies, but it didn't help. Still exit 1.

nowaker@nwkr-desktop ~/projekty/modern/worldmodern (git)-[rails71] % bundle update debug
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies...
Using debug 1.9.1 (was 1.8.0)
Bundle updated!
Gems in the group 'skip_on_arch_linux' were not updated.
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details
nowaker@nwkr-desktop ~/projekty/modern/worldmodern (git)-[rails71] % bundle update ruby-lsp-rails
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies...
Using prism 0.19.0 (was 0.18.0)
Fetching sorbet-runtime 0.5.11214 (was 0.5.11150)
Installing sorbet-runtime 0.5.11214 (was 0.5.11150)
Using ruby-lsp 0.13.4 (was 0.13.1)
Fetching ruby-lsp-rails 0.2.9 (was 0.2.8)
Installing ruby-lsp-rails 0.2.9 (was 0.2.8)
Bundle updated!
Gems in the group 'skip_on_arch_linux' were not updated.
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details
nowaker@nwkr-desktop ~/projekty/modern/worldmodern (git)-[rails71] % bundle update ruby-lsp-rspec
Fetching gem metadata from https://rubygems.org/........
Resolving dependencies...
Fetching ruby-lsp-rspec 0.1.9 (was 0.1.8)
Installing ruby-lsp-rspec 0.1.9 (was 0.1.8)
Bundle updated!
Gems in the group 'skip_on_arch_linux' were not updated.
1 installed gem you directly depend on is looking for funding.
  Run `bundle fund` for details

Neither Ruby 3.3.0 nor Ruby 3.1.4 works on this computer. Linux + RVM.

The exact same application with launch.json on my other computer works. Mac + RVM.

[Nowaker]

Any suggestions on what to do? If I'm given a quick primer on where to go and put some console.log and alike to provide more information on what exactly is failing, I'm happy to do it. Especially: tell me where you suspect is the line that triggers the "Debugger exited with status 1", and I'll take it from there.

[vinistock]

Thank you for the bug report! In the latest version of the extension, we started printing the debug server backtrace to the debug console if spawning fails.

If you try again, do you see the backtrace? That might help uncover what's failing.

[Nowaker]

In the latest version of the extension

Unfortunately, the latest version doesn't work for me at all but that's unrelated to this issue. Shopify/vscode-ruby-lsp#923 (comment) I'll come back to this one when RVM ends up working in the pre-release version.

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[vinistock]

We have shipped better RVM support in the stable version of the extension. If you can try this again, hopefully the debug console will print whatever errors occurred in the server, which can help us understand what's going on.

[github-actions]

This issue is being marked as stale because there was no activity in the last 2 months

[Nowaker]

I'll have a look this week. Sorry for the wait.

[vinistock]

I'll close this one for now. Since we shipped the upgraded integration for RVM, we have not received any related bug reports, so I'm hoping this has been fixed too.

If that's not the case, please do re-open.

[Nowaker]

Aight, thank you @vinistock.

[jklimke]

Hi. Unfortunately i am currently experiencing the same issue after the installing the most recent version of the vs code extension and the most up to date ruby-lsp gem. There are no error reports in the ruby-lsp output of vscode.

I also tried running the command manually and attaching the debugger afterwards, which works well.

[vinistock]

@jklimke do you happen to have bundler configs for your project or user? I suspect it could be related to #2519.

[jklimke]

@vinistock As far as i know i do not have configured a particular bundler config

The only thing that i have configured is the number of jobs for bundler.

bundle config
Settings are listed in order of priority. The top value will be used.
jobs
Set via BUNDLE_JOBS: 8

[GoldenSheep402]

I meet the same problem, even the .ruby-lsp folder is not created! And I will exit if I click the debug button

[Nowaker]

@vinistock It turned it this issue wasn't caused by RVM. I've not been encountering this issue for a while now, until I was able to trigger it again. Here's what happened.

First, I decided to bump appsignal gem:

modified: Gemfile.lock
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
-    appsignal (3.13.1)
+    appsignal (4.0.8)

bundle exec puma would normally use it. However, I noticed that Ruby LSP Debugger would load an older version of appsignal, inconsistent with what my Gemfile.lock wants!

So I set a breakpoint before Appsignal.set_error, then step into it, and stackframes point to appsignal-3.13.1.

This shouldn't really ever happen, given Ruby LSP uses Bundler when present on the project. But it is happening. So I do gem uninstall appsignal -v 3.13.1 and... I get this again:

So, I install it back with gem install appsignal -v 3.13.1 , and debug starts as normal again.

I'm in a pickle here. Unsure why/how Ruby LSP decides it should use an incorrect version of a dependency... And how it comes up with that version number to use in particular, given that gem version doesn't exist.

Any ideas what I could do, and what data to supply back, to help find the cause of this?

I checked #2519 and it seems unrelated. And I'm rocking Ruby LSP extension v0.7.20 so it should be fixed if it's at play.

[Nowaker]

Whoa! Ruby LSP does not obey Gemfile.lock!

A change in Gemfile.lock was totally ignored:

-    appsignal (3.13.1)
+    appsignal (4.0.8)

It also wants a change in Gemfile to work:

-gem 'appsignal'
+gem 'appsignal', '~> 4.0'

So when Gemfile and Gemfile.lock are both modified, Ruby LSP picks up appsignal-4.0.8 just fine - debugger starts, and I can step into it.

...This is of course totally unexpected, since Gemfile.lock is in charge of deciding the exact versions of dependencies to use when they're not defined in Gemfile, and of course for all dependency tree. Gemfile doesn't need to be updated in any way. A version bump performed via Gemfile.lock is absolutely fine... except for Ruby LSP. ;)

Now that I know the root cause, I can keep the version number of this dependency in my Gemfile, but let's take a step back and come up not just with a fix, but a generic logging mechanism that could help catch problems like these. What could "Ruby LSP" print in "Output" window to help understand the issue at hand? What's currently printed there is irrelevant to debugging this. And that exit 1 comes from somewhere... Nothing in stdout/stderr as Ruby LSP tries to run it? There could be a clue about missing appsignal-3.13.1. At least that would give a hint it's about dependency resolution.

[Nowaker]

I also noticed that after the first successful run of Ruby LSP with appsignal-4.0.8, I can now remove my Gemfile change and Ruby LSP is still activating appsignal-4.0.8. It no longer forces appsignal-3.13.1 in. That sounds like a bug in Ruby LSP's caching mechanism, I presume.

[vinistock]

Thank you very much for all the information, this is extremely helpful. This is what I believe to be happening:

1. When the language server launches, it sets up the custom bundle at .ruby-lsp to automatically include the ruby-lsp and debug gems
2. If your lockfile changes, we restart the language server, which re-runs the custom bundle logic, detects that the main lockfile has been modified and re-generates everything from scratch

Based on what you're saying, we're launching the debugger using the lockfile before it was updated somehow. The puzzling part for me is: are you not seeing the language server restart automatically upon modifying the lockfile?

I would've expected the restart to automatically correct the custom lockfile, which would then make launching the debugger work.

EDIT:

I also just realized this: the Ruby LSP debug client only attaches the debugger to the running process, but it doesn't control which dependencies are loaded by that process. Are you restarting the process you want to attach the debugger to after upgrading the gem?

That could explain the behaviour you're seeing, since the process would be using the old version of the gem.

[Nowaker]

Thanks for getting back to me @vinistock. Appreciate your help here.

If your lockfile changes, we restart the language server, which re-runs the custom bundle logic, detects that the main lockfile has been modified and re-generates everything from scratch

Uhm... And if I execute bundle update appsignal or git pull when my VS Code / Ruby LSP isn't running, is my debugging broken forever now? ;-) Just like it was for me for a couple months before it randomly started working again on this computer. (Supposedly, by updating Gemfile, which would then trigger a condition where the whole thing gets fixed again)

The puzzling part for me is: are you not seeing the language server restart automatically upon modifying the lockfile?

Unsure, since I use my own terminal to execute bundle update <dependency name> whenever needed, so my VS Code isn't in focus. Or I may be starting my work, and therefore git pull first, and then code . after that. I don't use a teeny tiny VS Code terminal on a daily basis.

If your lockfile changes, we restart the language server, which re-runs the custom bundle logic

I use VS Code on a daily basis. I also turn off my computer every day. That means Ruby LSP starts from scratch many times. However, the issue persisted across Ruby LSP restarts. That indicates it's not really about Gemfile.lock being watched for changes, but rather, something in Ruby LSP activation code not picking up on the fact Gemfile.lock was modified, and using its stale version for its own demise instead (or using some files/caches that were created based on the stale version of Gemfile.lock).

I also just realized this: the Ruby LSP debug client only attaches the debugger to the running process, but it doesn't control which dependencies are loaded by that process. Are you restarting the process you want to attach the debugger to after upgrading the gem?

Please don't get distracted by request=attach being mentioned here. :-) It was to give you an example that I am able to run the debug fine if I attach to it, but request=launch gets me exit 1 and no indication about what is going on and why.

This issue is solely about request=launch returning with exit status 1 when some Gemfile.lock changes were made that Ruby LSP isn't aware of.

[fiveNinePlusR]

@Nowaker can you share the contents of your vscode debugging configuration?

[Nowaker]

    {
      "name": "Rails",
      "type": "ruby_lsp",
      "request": "launch",
      "program": "puma" # or bundle exec puma, it doesn't matter, same problem
    },

[vinistock]

And if I execute bundle update appsignal or git pull when my VS Code / Ruby LSP isn't running, is my debugging broken forever now?
...
Unsure, since I use my own terminal to execute bundle update whenever needed, so my > VS Code isn't in focus. Or I may be starting my work, and therefore git pull first, and then code .
after that. I don't use a teeny tiny VS Code terminal on a daily basis.
...
I use VS Code on a daily basis. I also turn off my computer every day. That means Ruby LSP starts from scratch many times

Whenever the server launches, be it due to a restart, re-opening VS Code, automatic file watcher restart or any other trigger, we always check if the contents of the main lockfile are not matching the contents of the custom lockfile, so that we can then re-copy and start from scratch (see this line).

Updating a gem, even if you do it in a separate terminal or with the editor closed, should make no difference. When you open VS Code, it will compare the SHA digest of the previous lockfile content vs the current one and re-generate if needed.

Based on this comment

It also wants a change in Gemfile to work:

I suspect there's some Bundler related issue at play. We don't even watch the Gemfile or do anything with it, since what controls the versions is the lockfile. The only impact that adding a constraint to the Gemfile would have is to force Bundler to resolve versions in a certain way.

Do you happen to have any global (~/.bundle/config) or project (~/path/to/project/.bundle/config) Bundler settings? We did just merge #2535, which fixes handling of Bundler setttings.

[Nowaker]

Do you happen to have any global (/.bundle/config) or project (/path/to/project/.bundle/config) Bundler settings? We did just merge #2535, which fixes handling of Bundler setttings.

Yes:

% cat ~/.bundle/config
---
BUNDLE_JOBS: '20'
BUNDLE_RETRY: '5'
BUNDLE_BUILD__NOKOGIRI: "--use-system-libraries"
% cat .bundle/config 
---
BUNDLE_WITHOUT: "skip_arch"

But I was already on that version when I found the cause of this issue.

I suspect there's some Bundler related issue at play. We don't even watch the Gemfile or do anything with it, since what controls the versions is the lockfile. The only impact that adding a constraint to the Gemfile would have is to force Bundler to resolve versions in a certain way.

I mean, it surely is about Bundler. But it isn't a Bundler issue alone - it's an issue triggered by Ruby LSP. Bundler alone works fine, I can bundle exec puma and it loads the correct dependency. Even when I execute the command Ruby LSP advertises to execute when debugging, it starts, listens, and I can connect to that socket via request=attach. But when it's request=launch executed by Ruby LSP, an older version of appsignal is being pulled in. If you happen to still have it installed locally, it will work. But if you gem uninstall it, then it's exit status 1 and no indication as to why it's exit 1.

It's clear as day it's something in Ruby LSP triggering this incorrect behavior, and all my experience tells me it's a caching mechanism. Old Gemfile.lock? I can't tell.

Ruby LSP has some caching - a quick search reveals this one, for example:

ruby-lsp/lib/ruby_lsp/setup_bundler.rb

Line 94 in a4f5a2d

if @custom_lockfile.exist? && @lockfile_hash_path.exist? && @lockfile_hash_path.read == current_lockfile_hash

. I don't know if it's related to my issue.

And I'm also unsure if this entire bundle setup thing is happening for request=launch. And if so, why? Since it's just an rdbg call, which requires debug in Gemfile (which mine has), there is absolutely no need for Ruby LSP to perform any of what I'm seeing in RubyLsp::SetupBundler. I understand it's important for the language server, especially to gem its version up to date, but I don't see how it has any use for request=launch in particular.

2024-01-22 20:33:18.537 [info] Spawning debugger in directory /home/nowaker/projekty/modern/worldmodern
2024-01-22 20:33:18.537 [info]    Command bundle exec rdbg --open --command --sock-path=/tmp/ruby-lsp-debug-sockets/ruby-debug-worldmodern-0.sock -- puma
2024-01-22 20:33:18.537 [info]    Environment {"RAILS_DEBUG":"true","SHELL":"/usr/bin/zsh" .......

AFAIR, I even replicated the same environment variables back then. And it would still just start, and listen. And then I would attach from VS Code. But having the plugin do it, it exits 1.

If we're back to square one, let's go back to February:

Any suggestions on what to do? If I'm given a quick primer on where to go and put some console.log and alike to provide more information on what exactly is failing, I'm happy to do it. Especially: tell me where you suspect is the line that triggers the "Debugger exited with status 1", and I'll take it from there.

In the latest version of the extension, we started printing the debug server backtrace to the debug console if spawning fails. If you try again, do you see the backtrace? That might help uncover what's failing.

Nope. No backtrace. Still the same output as before.

I've recorded a video for you to see how easy it is for me to reproduce this issue and show it's about an old dependency being retained (somehow).

1. Start with gem appsignal in Gemfile. Have it locked at 3.11.1 in Gemfile.lock.
2. Start via bundle exec puma. Shows 3.11.1 in use.
3. Start via VS Code. Shows 3.11.1 in use.
4. bundle update appsignal without any changes in Gemfile. Only Gemfile.lock has it.
5. Start via bundle exec puma. Shows 4.0.9 in use.
6. Start via VS Code. Shows 3.11.1 in use. (!!!)
7. gem uninstall appsignal -v 3.11.1
8. Start via bundle exec puma. Shows 4.0.9 in use.
9. Start via VS Code. Exit 1. (!!!)
10. (next video file since I just came up with one more thing to show you)
11. (repeat of no 9 just to show we're continuing the same scenario, nothing new here) Start via VS Code. Exit 1. (!!!)
12. Modify gem 'appsignal' to gem 'appsignal', '4.0.9'
13. Start via VS Code. Shows 4.0.9 in use.
14. Modify Gemfile to gem 'appsignal', '4.0.9'
15. Start via VS Code. Shows 4.0.9 in use.
16. Modify Gemfile to gem 'appsignal'
17. Start via VS Code. Shows 4.0.9 in use.
18. Modify Gemfile to gem 'appsignal', '~> 3.0.0, then run bundle update appsignal
19. Start via VS Code. Shows 3.0.27 in use.
20. Modify Gemfile to gem 'appsignal'
21. Start via VS Code. Shows 3.0.27 in use.
22. gem update appsignal (to bump to 4.0.9)
23. Start via VS Code. Shows 3.0.27 in use. (!!! - 4.0.9 expected)
24. Modify Gemfile to gem 'appsignal', '4.0.9'
25. Start via VS Code. Shows 4.0.9 in use.
26. Modify Gemfile to gem 'appsignal'
27. Start via VS Code. Shows 4.0.9 in use. (Expected - but note how it continued using 4.0.9 - which means it remembered it from the previous run)
28. Modify Gemfile.lock to appsignal-4.0.9 appsignal-4.0.8 (typo; video shows 4.0.8, obviously)
29. Start via VS Code. Shows 4.0.9 in use. (!!! - 4.0.8 expected)

• Video 1: https://github.com/user-attachments/assets/aed7f640-2f01-477b-bdda-1aeba282418a
• Video 2: https://github.com/user-attachments/assets/2f8f714c-06d3-4d33-b626-f14542bc634c

It's pretty clear my Gemfile.lock isn't in charge when running via Ruby LSP. It's like you use it for the first time, but subsequent changes are ignored in it, unless I make a change in Gemfile.

[malcolmohare]

I see the same, but opposite, issue.

The RubyLsp generated lockfile does not obey the contents of my projects own lockfile. For at least the immediately problematic gem, it selected a much newer version (dry-monads 1.6.0 vs 1.3.5), which my application is not compatible with. This dependency gem is not declared in my Gemfile, its a dependency of a dependency, and the version is not specified where its declared. But either way, I would ASSUME the RubyLsp would honour my projects lockfile and not go pick its own versions.

So when I run the rdbg command from the terminal from my workspace root, everything is fine and I can happily attach. But when I use CodeLens, I assume the extension is telling it to use the Lsp gemfile via BUNDLE_GEMFILE=[workspace]/.ruby-lsp/Gemfile and now its getting the wrong version of dependencies. At least, from the RubyLsp output and the Environment vars its spitting out when its running the command, that seems to be what is happening.

I'm wondering to myself, why would I want the debug process to use the lsp gemfile? That itself seems like a bug. I'm going to try and fix this myself and put up a PR.

But also, the gem versioning thing is concerning, but I don't know enough about the Lsp to know what else this could be affecting.

[Nowaker]

Wait, the plugin generates its own Gemfile?! So I've been right all along!

using its stale version for its own demise instead (or using some files/caches that were created based on the stale version of Gemfile.lock)

Too bad I never saw .ruby-lsp/Gemfile! Given that, I'd like to re-raise the question I asked in my previous comment:

Why [is this entire bundle setup thing happening for request=launch]? Since it's just an rdbg call, which requires debug in Gemfile (which mine has), there is absolutely no need for Ruby LSP to perform any of what I'm seeing in RubyLsp::SetupBundler. I understand it's important for the language server, especially to [keep] its [gem] version up to date [without requiring a constant bundle update ruby-lsp-rails], but I don't see how it has any use for request=launch in particular. [Especially now, knowing it causes unexplained exit 1 in certain situations.]

[malcolmohare]

There was a time when it didn't do this custom bundle for debugging, but then one day this: f55b903

It's a nice feature IF the users repo didn't include the debug gem, but when it does, its causing these issues. I guess the history/usage of the custom bundle expanded over time so what was once an edge case is the every case.

[Nowaker]

There was a time when it didn't do this custom bundle for debugging, but then one day this: f55b903

Nice find. Allowing us to opt out of using LSP's bundle would be as easy as this:

    if (fs.existsSync(customGemfilePath) && !debugConfiguration.env.IGNORE_LSP_BUNDLER) {
      debugConfiguration.env.BUNDLE_GEMFILE = customGemfilePath;
    }

But a proper fix would be to actually "Fix debugger launch configurations when debug is not included in the bundle" and not "Force RubyLsp::SetupBundler whether debug gem is in the bundle or not". Because it is in mine, and yet RubyLsp::SetupBundler is happening for no good reason.

[jklimke]

I noticed that the .ruby-lsp/Gemfile.lock was heavily outdated compared to my projects gemfile.

As a quickfix to be able to debug deletion of this .ruby-lsp/Gemfile.lock or the whole .ruby-lsp folder worked for me to be able to debug again.

[malcolmohare]

Removing the chunk of code that sets BUNDLE_GEMFILE causes the debugging command to not work. Changing that ENV to point at the workspace Gemfile instead of the ruby-lsp Gemfile did what I wanted. I just need to figure out how to make that a per workspace setting or how to detect the presence of the debug gem in the main Gemfile. 🤔

[malcolmohare]

I've got a pull request up for adding a new setting, which allows users to specify the path to the Gemfile to use when running in debug. If the setting is blank, nothing changes.

#2707

This fixes the issue I was having, where the Gemfile the LSP generated in the lsp-ruby file had newer and incompatible versions of gems I used, and thus failed when parsing the code it was running. This fixes that, and it works fine, as long as your Gemfile contains the debug gem.

[nitsujri]

I'm running into a similar (but possibly different? no incompatible gems) issue.

I can run it just fine via normal Run Test and attach (as discussed here), but when I run a spec via Debug Test:

• The Testing Explorer immediately returns as passed

• Debug Console has entire output which at the end includes:

  .... (full, proper test output) ...
  DEBUGGER: Disconnected.
  Debugger exited with status 1. Check the output channel for more information.
  

  This is another key difference, I don't get the pop up in VSCode it actually runs and all output just shows up inside the Debug Console. I can provide the text if it helps.

Things Tried

• Adding ruby-lsp & ruby-lsp-rails to my gemfile, deleting .ruby-lsp/ - same problem above.
• Was hoping it was an incompatible gem (like @malcolmohare), but diffing the 2 gemfiles shows no real changes

[vinistock]

Just wanted to share an update: I managed to reproduce this with tests and I believe I have a fix for it. It's related to how the composed bundle environment is not reported back to the extension, which makes us try to launch the debugger with the wrong Bundler settings.

I'm waiting on PR reviews until I can submit the related changes. Once everything is in replace, I'll ask the folks here to test it out.

[Nowaker]

@vinistock Thanks!

[vinistock]

Okay, I believe with v0.8.14 for the extension and v0.22.0 for the server, this problem will be fixed.

If that's not the case, please let us know.