Received cancel notification for unknown message id #

[npradeep357]

I installed pylsp and all required modules. Integrated it with node server and started the service. Everything is working as expected except when ever there is $cancelRequest from client (language client), server throws this error.

Even though the response comes, but it is noticeably slow. pylsp takes a few seconds to response after this request.

here is the sample output from my service whenever this cancel request is sent

here are my client requests and we can clearly see the response time delay:

[bicobus]

I have this kind of issue too. Would you kindly tell us which editor is failing? I'm using emacs with lsp-mode. If other clients have that trouble too, then it may be some other trouble pylsp is having.

[npradeep357]

I have this kind of issue too. Would you kindly tell us which editor is failing? I'm using emacs with lsp-mode. If other clients have that trouble too, then it may be some other trouble pylsp is having.

I'm facing this issue with Monaco editor. Between, my client is web based (Javascript).

[hugorichard]

I am using spacemacs and face this as well See also this issue where many users face the same issue: https://github.com/palantir/python-jsonrpc-server/issues/17

[npradeep357]

Hi, just an update:

Later I changed my web editor to code mirror and I'm sure that I did not face this issue again with code-mirror language client.

I think the issue is the kind of request the client is sending for which the server is not able to response properly.

[davschul]

Hi, I'm currently working on integrating the python lsp into Qt Creator. I also get a lot of these messages especially for bigger files where a completion might take a couple of seconds. One of the major issues seems to be that requests are handled strictly in order. For example imagine the following requests are received by the server:

1. synchronous request id 1
2. cancel request id 1
3. synchronous request id 2
4. cancel request id 2
5. synchronous request id 3

After receiving the first request the server gets busy and doesn't handle any new incoming messages from the client. While it computes the result for request 1 the client sends the remaining messages from the example.

After completing request 1 the server checks for the next message, but cannot find a request for that id. This could be avoided by tracking all previously received ids, and just don't react on canceled requests that were already completely handled.

Now the server takes the next message in the queue, the request with id 2, and startes computing a result for a request that was already canceled by the client. And this results in a delayed computation of the result for request 3.

This strictly linear handling of the message can stack quite a bit from my experience. Especially when modifying the documents content. The server starts to compute the diagnostics, the document symbols and document highlight needs to be updated we might want to have a completion either explicitly or by a trigger character. And if the document contents get changed again while the requests were already send to the server the cancelation of those requests just don't happen at all.

This might be fixable with an asynchronous handling of the incoming messages were just the messages are parsed and thrown into a queue. If a cancel message get's received in this asynchronous parser:

• if computation has not yet started: remove the message from the queue
• if it is an async computation cancel the future
• if it is currently handled save the cancel and when the computation is done check whether it was canceled while comuting the result

Any opinions on the issue or on the proposed solution?

[hugorichard]

Your explanation seems reasonable. I don't have the expertise to help on this matter. But if you do solve this issue, I will be very happy !

[ccordoba12]

Any opinions on the issue or on the proposed solution?

Sounds good to me. If you're planning to implement it, even better.

[davschul]

I investigated some time into researching asyncio and also implemented a very rudimental work in progress async interface. Since I'm not quite sure whether I'm moving into the right direction I would like to get early opinions on the code and the solution. The api is implemented in https://github.com/davschul/python-lsp-jsonrpc/tree/async and is used by https://github.com/davschul/python-lsp-server/tree/async. Should I create a pull request to discuss these changes or are other communication channels preffered?

[ccordoba12]

Nop, please create pull requests so we can take a look at them. And thanks a lot for your help with that @davschul!

[npradeep357]

@davschul can you check the latest changes in python_lsp.py file. I have added some changes which includes asyncio, though these are specifically for websockets use case (start_ws_lang_server function).

If the LSP server itself can start in asyncio(using start_async method from your changes), then some part of the code written for websockets can be moved or reused or removed.

Please have a look at latest code and let me know...

Thank you

[slacksystem]

Hi I'm not super familiar with the solutions involved here, so I may be misinterpreting a comment or something, but I'm having the same issue and I'm wondering if anyone found a solution? Apologies if that info was present and I missed it

[tmnvanderberg]

Having the same issue in Kate.