Volar crashes shortly after after startup #706
Comments
|
I've intercepted all stdin and stdout: stdin: stdout: stderr is empty. |
|
See also neovim/nvim-lspconfig#1436 |
|
Yep please track neovim/nvim-lspconfig#1436, thanks. |
|
Will do. Do you have any hints on debugging crashes tho? If Volar exited abruptly, how would you to pinpoint the cause? Any suggestions you may have are most welcome! |
|
My spider sense tells me this could have something to do with https://github.com/neovim/nvim-lspconfig/blob/62a275d1050f930eabbf545edd1bdc5aa9372594/lua/lspconfig/volar.lua#L65. In your "typescript":{"serverPath":"\/home\/hugo\/clones\/gitlab.com\/fotus\/photostore\/vue3\/node_modules\/typescript\/lib\/tsserverlibrary.js"Are you sure the above path is available from within the container? I've seen you've only bind-mounted some other folder local cmd = { 'podman', 'container', 'run', '--interactive', '--workdir=/home/hugo/tmp/vue3', '--volume=/home/hugo/tmp/vue3:/home/hugo/tmp/vue3', 'volar' } -- needed for elixirls, omnisharp, sumneko_luaThe nvim-lspconfig config for volar launches volar in a way that's dependent on typescript being installed in your project's node_modules If volar trying to start with tsserverlib.js that's not bound to the container is causing your crash, the solution could be to The downside is that you'd be using your global typescript instead of your project's local TS version. But you can also try to bind mount the local node_modules/typescript folder too instead of binding the global TS dir. There's some more about TS detection in the changed files in neovim/nvim-lspconfig#1316 Custom TS Detection section |
|
@johnsoncodehk I don't think this is an lspconfig issue, rather an issue with the containerization of Volar. AFAIK volar works fine with lspconfig/the built-in client. My guess would be, as @sethidden has suggested, that it's something to do with needing access to libraries/paths not bind-mounted into the container. |
|
Sorry, I moved to testing a project in I'm using this code to run the container and do the mounting: https://github.com/lspcontainers/lspcontainers.nvim/blob/main/lua/lspcontainers/init.lua the minimal_config is probably easier to reason about tho. Is there any way to make Volar print an error when exiting, rather than exiting silently? |
This comment has been minimized.
This comment has been minimized.
|
It might be polluting stdio with the log messages. |
|
🤦 right Really weird issue. Tried debugging the volar server with node (exposed debug port 9229 from the container). Set up "pause on exceptions" but volar just dies without any exception happening EDIT: Still nothing. |
|
I've tried adding I've been using this wrapper to make sure I capture all stdin/stdout/stderr: https://git.sr.ht/~whynothugo/lspdebugger/tree/main/item/main.go And this dockerfile: FROM alpine:3.13.5
RUN apk add --no-cache \
nodejs \
npm
# ARG VERSION
RUN npm install -g @volar/server
COPY lspdebugger /usr/bin/lspdebugger
CMD [ "/usr/bin/lspdebugger" ]
# CMD [ "volar-server", "--stdio" ] |
|
Sorry I don't have a clue about this problem for the time being, and I don't even know how to setup reproduce env. It would be helpful if there are some guidelines, I will try to check it when I have time.
|
|
The mechanism of action is very similar to this: typescript-language-server/typescript-language-server#262 The onInitialize fn receives a params arg, which has params.processId. The problem is I think that that process (params.processId) just immediately dies inside the container (ie. if I set a breakpoint somewhere then run "top" to see running processes inside the container, there is no process with that processId) Then the process watcher mentioned in typescript-language-server/typescript-language-server#262 (comment) kills the langserver with signal code 1 when it sees that the processId doesn't exist |
|
Can you try with the podman/docker arg |
IT WORKS!!! Thanks! Now I kinda feel stupid debugging the actual code for so many hours when it was just a process spawning issue hah (--network=host is probably unnecessary, I used it for debugging) |
|
Generally you probably want to do this for containerizing language servers as many servers check the PID of the client that spawned them for self-termination, I think omnisharp does this as well. |
|
Nice, yes, this works! I wonder if this auto-detection can be disabled for the LSP through some flag. Other LSPs don't have this detection-of-parent (at least I assume they don't or they'd exit immediately), and this check assumes that the server is running on the same host as the client which isn't always the case. I appreciate the help debugging this, I don't think I would have ever figured it out. |
|
Oh, actually, that feature can be disabled by using: volar = {
before_init = function(params)
params.processId = vim.NIL
end,
cmd = lsp_containers.command("volar", { image = "volar" }),
},I guess there's not much to be done here. microsoft/vscode-languageserver-node#857 should suffice for improving the experience when other hit this same issue. Feel free to close this. |
|
@sethidden Thank you for your efforts! |
Volar seems to start fine, shows a few diagnostics, and then dies after a second or two.
I'm running it containerised (via
podman). I looked at #514, but I'm not convinced I'm seeing the same issue.This is all of neovim's debug output for the LSP:
I'm actualy just using the same project generated via
npm init vite@latest, and the pickingvue-ts. I haven't made any changes to it.This is the
Dockerfilefor the container I'm using:Any hints on what could be up?
The text was updated successfully, but these errors were encountered: