Overwhelming number of signature requests/flooding language server implementation

compyman commented 2 years ago

Thank you for the bug report

[X] I am using the latest version of lsp-mode related packages.
[X] I checked FAQ and Troubleshooting sections
[ ] You may also try reproduce the issue using clean environment using the following command: M-x lsp-start-plain

Bug description

I'm having issues with python-lsp-server (pylsp) - I am able to configure/connect to a pylsp server in my virtualenvironment - but - it often times will use 100%+ of my CPU (as reported by top) and crucially - totally freeze emacs!

There's an issue in the python-lsp-server repo here: https://github.com/python-lsp/python-lsp-server/issues/227

It looks like - lsp-mode is sending over signature requests or other commands on every keypress, and then cancelling the previous request. However it looks like python-lsp-server does not support cancel requests, so all of those requests bring everything to a halt unless I type very very slowly.

Is there any configuration to... only send requests after a certain amount of time has passed from a keypress? (maybe only on servers that don't support canceling?) or any other advice for configuration or other python servers that don't have this issue?

Steps to reproduce

(I think a somewhat large project is required)

start a pylsp session in a somewhat large project - start filling out a signature or function body pretty quickly.
View in the lsp io logs that many signature requests are being sent
also notice that many cancellation requests are being sent (to cancel the previous signature request)
each cancellation request should receive an error
after a few seconds pylsp uses ~100 CPU and emacs freezes

Expected behavior

lsp-mode to not flood the language server with requests if the server is unable to cancel them

Which Language Server did you use?

pylsp

OS

Linux

Error callstack

No response

Anything else?

mentioned in the discord here: https://discord.com/channels/789885435026604033/789890622424219658/1018883658226085970

svenssonaxel commented 1 year ago

Perhaps this is two separate issues:

When a server does not support cancelling requests, lsp-mode should probably throttle requests instead.
Perhaps requests should use an asynchronous process to not lock the interface in case the reply takes a long time.

compyman commented 1 year ago

I think so! both would be great.

kcbanner commented 1 year ago

A way to throttle requests would be great, I'm currently hitting the same issue with zls

satyanash commented 1 year ago

This is quite easily reproducible with lsp-mode and python-lsp/python-lsp-server, and makes the combination unusable. Is there a temporary workaround/configuration for lsp-mode that can make it usable until we address the root cause mentioned by @svenssonaxel ?

satyanash commented 1 year ago

Collecting all related issues to this slowdown here:

This is quite a widespread issue.

malashinroman commented 1 year ago

I am facing the same issue in neovim, every keypress produces error and in a few minutes lsp commands turn to be veeery slow

ZedThree commented 1 month ago

I tried using lsp-jedi with jedi-language-server, and I see exactly the same behaviour as with pylsp: CPU pinned to 100%, auto-complete taking >8 seconds

I see very similar messages in *jedi::stderr*:

WARNING:pygls.protocol.json_rpc:Cancel notification for unknown message id "501"
WARNING:pygls.protocol.json_rpc:Cancel notification for unknown message id "503"
WARNING:pygls.protocol.json_rpc:Cancel notification for unknown message id "505"
WARNING:pygls.protocol.json_rpc:Cancel notification for unknown message id "506"
WARNING:pygls.protocol.json_rpc:Cancel notification for unknown message id "507"

emacs-lsp / lsp-mode