Overwhelming number of signature requests/flooding language server implementation

[compyman]

Thank you for the bug report

• I am using the latest version of lsp-mode related packages.
• 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: python-lsp/python-lsp-server#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]

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]

I think so! both would be great.

[kcbanner]

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

[satyanash]

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]

Collecting all related issues to this slowdown here:

• Python LSP server completely stops working after a cancel notification is received python-lsp/python-lsp-server#114
• Received cancel notification for unknown message  palantir/python-jsonrpc-server#17
• Received cancel notification for unknown message id # python-lsp/python-lsp-jsonrpc#5
• pyls extra slow and a lot of warnings #1731
• Received cancel notification for unknown message  palantir/python-jsonrpc-server#17

This is quite a widespread issue.

[malashinroman]

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]

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"