search

Shopify / ruby-lsp

An opinionated language server for Ruby
https://shopify.github.io/ruby-lsp/
MIT License
1.52k stars 144 forks source link

"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 #1767

Open Nowaker opened 8 months ago

Nowaker commented 8 months ago

Operating System

Linux

Ruby version

3.3.0 / 3.1.4

Project has a 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.

image

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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. https://github.com/Shopify/vscode-ruby-lsp/pull/923#issuecomment-1925444162 I'll come back to this one when RVM ends up working in the pre-release version.

github-actions[bot] commented 4 months ago

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

vinistock commented 3 months ago

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[bot] commented 1 month ago

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

Nowaker commented 1 month ago

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

vinistock commented 1 month ago

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 commented 1 month ago

Aight, thank you @vinistock.

jklimke commented 1 week ago

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 commented 1 week ago

@jklimke do you happen to have bundler configs for your project or user? I suspect it could be related to https://github.com/Shopify/ruby-lsp/issues/2519.

jklimke commented 1 week ago

@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 commented 1 week ago

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

Nowaker commented 4 days ago

@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.

Image

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:

Image

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 https://github.com/Shopify/ruby-lsp/issues/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 commented 4 days ago

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.

Image

...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 commented 4 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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

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

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 commented 2 days ago

Do you happen to have any global (~/.bundle/config) or project (~/path/to/project/.bundle/config) Bundler settings? We did just merge https://github.com/Shopify/ruby-lsp/pull/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: https://github.com/Shopify/ruby-lsp/blob/a4f5a2d780950816829bd1372f559979d947e7cd/lib/ruby_lsp/setup_bundler.rb#L94. 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
  29. Start via VS Code. Shows 4.0.9 in use. (!!! - 4.0.8 expected)

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.