LSP :: Sending to process failed with the following error: Process pyright-remote not running

[tshu-w]

Sometimes when the connection to the remote server is disconnected or the server quit?, I got

LSP :: Sending to process failed with the following error: Process pyright-remote not running [8 times]

now, I cannot shut down or restart the server, both got the above message. I tried to disconnect, enable lsp-mode again by M-x lsp-mode, and start the server, this complaint is still there. The only thing I can do is restart Emacs, and I was wondering if there will be a more harmless way to restart the process.

*lsp-log*

Command "pyright-langserver --stdio" is present on the path.
Command "pyright-langserver --stdio" is present on the path.
Found the following clients for /ssh:144:/data/wts/entity_resolution/data/wdc/images_crawler.py: (server-id pyright-remote, priority 0)
The following clients were selected based on priority: (server-id pyright-remote, priority 0)
Command "pyright-langserver --stdio" is present on the path.
Command "pyright-langserver --stdio" is present on the path.
Found the following clients for /ssh:144:/data/wts/entity_resolution/data/wdc/images_crawler.py: (server-id pyright-remote, priority 0)

*lsp-log: *

[Trace - 02:31:24 PM] Sending request 'shutdown - (922)'.
Params: {}


[Trace - 02:31:25 PM] Sending notification '$/cancelRequest'.
Params: {
  "id": 922
}


[Trace - 02:31:25 PM] Sending notification 'exit'.
Params: null


[Trace - 02:31:37 PM] Sending request 'shutdown - (923)'.
Params: {}


[Trace - 02:31:38 PM] Sending notification '$/cancelRequest'.
Params: {
  "id": 923
}


[Trace - 02:31:38 PM] Sending notification 'exit'.
Params: null


[Trace - 02:31:40 PM] Sending notification 'textDocument/didClose'.
Params: {
  "textDocument": {
    "uri": "file:///data/wts/entity_resolution/data/wdc/images_crawler.py"
  }
}

maybe related: https://github.com/emacs-lsp/lsp-mode/issues/1461 https://github.com/emacs-lsp/lsp-mode/issues/1710

[ericdallo]

I already had this with clojure-lsp, but is not easy to repro, any thoughts @yyoncho?

[muirdm]

I get stuck like this sometimes as well. Maybe lsp-shutdown needs to clear out all metadata even if the server process isn't currently running?

[yyoncho]

I get stuck like this sometimes as well. Maybe lsp-shutdown needs to clear out all metadata even if the server process isn't currently running?

yes, cleanup is buggy.

[muirdm]

FYI if you clear out lsp--session (e.g. M-: (setq lsp--session nil)) it will retry properly next time you active lsp-mode.

[nrnrnr]

Alas, the lsp--session trick is not working for me.

[ahmed-shariff]

The lsp--session hack doesn't work for me either. In my case, I switch between projects with python (pyright), csharp (omnisharp) and js (ts-ls) using persp-mode. I get these errors on all servers, but not always. Haven't been able to always recreate this issue, which makes it supper frustrating to debug. For the time being is there a way to suppress this error?

[unhammer]

I did (setq lsp--request-cleanup-hooks (ht)) and that seems to have stopped the noise for now (try (setq debug-on-message "not running") to catch the backtrace, though set it to nil right after it's caught). Seems like it's stuck trying to cleanup stuff that's already cleaned up?

Really annoying when this happens. I've seen it with both ccls and lsp-haskell, maybe others.

[vherrmann]

I found that (at least in my setup) the global hook variable post-command-hook isn't cleared of the hooks added in lsp--send-request-async. Probably this holds for the other hook variables as well, but since they are set buffer-local, the lsp-hooks „vanish“ the moment the code buffer using lsp-mode is closed (I only have this problem sometimes when I close a code buffer using lsp). The problem maybe arises from lsp--send-request-async trying to remove the lsp-hooks by comparing against new closures, created with the same parameters (maybe the problem arises from byte or native-compilation?).

I fixed it temporarily by removing all lsp-hooks from post-command-hook.

[vherrmann]

The hack

(setq-default post-command-hook
              (--filter (not (and (consp it)
                                  (eq (car it) 'closure)
                                  (not (-difference
                                        '(cancel-callback method buf hook workspaces id)
                                        (-map #'car (cadr it))))))
                        (default-value 'post-command-hook)))

works for me (at least sometimes). The following hack:

(add-hook 'kill-buffer-hook
          (lambda ()
            (when (bound-and-true-p lsp-mode)
              (setq-default post-command-hook
                            (--filter (not (and (consp it)
                                                (eq (car it) 'closure)
                                                (not (-difference
                                                      '(cancel-callback method buf hook workspaces id)
                                                      (-map #'car (cadr it))))))
                                      (default-value 'post-command-hook))))))

executes the first snippet automatically when a buffer with lsp-mode is killed. So it might fix the issue permanently.