-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LSP seems to fail when hovering things #4416
Comments
Thanks for the bug report, but I'm unable to repro the problem you're seeing. Do you have any additional steps you could offer? Which file are you hovering in when the problem occurs? What function/symbol are you hovering over? |
Okay, this sounds crazy but bear with me:
(I additionally have the debug terminal open and see that the language server starts while I am already switching files and then it throws that error). |
Hmm, I'm still not able to repro the problem. The "textDocument/hover" command is sent only when your mouse pointer is hovering over a part of the front-most document. When you scroll through the files, I presume that your mouse pointer is positioned within that document window? If so, where in the file is it pointing when the crash occurs? Could you try setting "python.analysis.logLevel" to "Trace"? That should provide more detailed debug information. |
Well the errors that I get with cycling through the files are not hover but I have increased to trace and this is what I see while cyling through:
|
@apollo13 is this regular pyright from vscode market place? if not, where did you get the vsix? asking since there might be some hint why this is happening if I can take a look at the content of the vsix you are using. |
@dbaeumer this looks to be happening here: Might this have been fixed by this here? Meaning this might be happening if the VSIX has an older version of LSP in it. |
Also, please let us know which version of VS Code you're running. If you're not on the latest production build, please update and see if that addresses the problem. |
Hi, I am running VSCodium 1.74.2:
I think VSCodium uses https://open-vsx.org/ since microsoft doesn't allow other builds to use the marketplace. If this is indeed causing this issue I am very sorry. I thought that a Code build from the official sources should basically behave like Code from Microsoft sans the telemetry (same for open source extensions). Please let me know if I can provide any further information. |
Please try it with an official VS Code build. We don't test with VSCodium releases. In theory, it should work, but it's not officially supported. Since VSCodium is fully open-sourced, you may should have everything you need to debug the problem yourself. |
Hi @erictraut -- Ok thank you. I did got a bit further and noticed that my pyright extension was not actually built from the latest published version but rather from b3f57ed. So I think this issue might occur on original VSCode as well if using the extension from git. That said I am currently failing to build it. I tried following https://github.com/microsoft/pyright/blob/main/docs/build-debug.md#building-the-vs-code-extension to get an extension that I can try on VSCode proper but I get errors like:
Do you have any tip for me what I might be doing wrong? |
Okay, I have used a docker container with node 14 as required here https://github.com/microsoft/pyright/blob/main/docs/build-debug.md#building-pyright but I needed an up2date npm to build it. And heureka, reproduced on a original VSCode with pyright revision ddc6932: @erictraut Would you mind reopening this, or are issues against the main branch also not wanted? |
It's highly unlikely that this is a regression on the pyright main branch. Since you're able to repro the problem with the latest main branch, then I presume you can also repro it with the latest published version of pyright (1.1.287), which was published just 4 days ago. Can you please verify by installing the latest version of pyright from the marketplace? The challenge now is to determine why you're seeing this on your system when we are not able to repro it elsewhere and no other pyright or pylance users have reported it. At the top of the issue, you mentioned a particular project (goodconf). Are you able to repro the problem with other projects, or does it seem to be specific to this code base? I'm guessing that it will happen with any code base, but just wanted to confirm since you specifically mentioned that project. |
Pyright 1.1.287 from the MS marketplace does not exhibit the problem.
Ok, let me know how to figure out more.
Yes also happens on a checkout of Django, so I guess every python project. I have attached my build (rename from zip to vsix) from current main. I'll happily do whatever I can to help debugging this, I am just somewhat out of my debt here. |
As a counter check I am now building 1.1.287 (the tag) directly and will check against that to rule out issues with my build environment. |
The tag 1.1.287 built manually is fine as well, I am going to bisect the commits now. |
@erictraut b78a9e4 Is the commit that introduces the broken behavior. So I guess this might be a "bad" back-merge and users are not seeing it yet because it is fine in pylance and not yet in a released version of pyright? |
I just realized that our build instructions were a bit out of date. Please make sure that you're using node 16.x for your build and that you're running `npm run install:all" to update dependencies. |
Based on what you're seeing, I suspect that there was something broken in @heejaechang, @rchiodo, @dbaeumer, any thoughts on this theory and potential root cause? |
I just built with node 16 no joy. Rolling back solely
|
OK, it looks like I'm still not able to repro the problem you're seeing on my MacOS system. Perhaps it's specific to Linux. @apollo13, thanks for your diligence and willingness to help diagnose the problem. I'll leave it to others on this thread to further isolate the problem since they're more familiar than I am with the internals of the Update: I was just able to repro the problem on MacOS, but it happens inconsistently and rarely. (I have a fast M2 processor, and I suspect that timing is an issue here. Cancellation applies only when the previous LSP operation is still pending when the next operation is requested, so cancellation doesn't come into play as much on fast systems.) |
The error core /**
* The client has canceled a request and a server as detected
* the cancel.
*/
export const RequestCancelled: integer = -32800; So it should only be returned by a server if the request is canceled and the server decides to not compute any result. Then the LSP client for VS Code will return a corresponding value to the VS Code API that VS Code will ignore. If the server returns this for a request that has not been canceled by the client the client will log this. This might have gotten fixed in a newer release. The part in the spec is here https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#errorCodes and here https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#implementationConsiderations Could it be that in the described scenario the server returns |
@heejaechang, I've looked through the pyright code, and I don't see anywhere the server would send a |
I think I went down the wrong path with this. The change that makes this being logged now is the additional The |
Started to work on a fix: microsoft/vscode-languageserver-node#1169 Will comment here when a new next version is available to test. |
Published client@8.1.0-next.5 and server@8.1.0-next.5 Let me know if this addresses the issue you are seeing |
@dbaeumer, thanks for the quick fix. I'll include the update in the next version of pyright. |
The update was pulled in via #4443 and it seems to have fixed the issue at hand. Thank you! Note for anyone else stumbling onto this; this should be fixed in the yet to be released 1.1.289 |
This is included in pyright 1.1.289, which I just published. It will also be included in a future release of pylance. |
Describe the bug
I am not sure to describe it properly, I have a checkout of goodconf (https://github.com/lincolnloop/goodconf) and when starting vscode and doing things (I don't even know what exactly, it is not exactly reproducible when I try) I get this popup:
And the console shows:
Aside from that pyright seems to work properly.
To Reproduce
Open the referenced project in vscode, set the python interpreter to a venv with all dependencies and play around.
Expected behavior
No Error.
VS Code extension or command-line
VSCode extension version v1.1.287
Additional context
I am sorry for this vague bug-report, please let me know what further information I can provide and if I can somehow help debugging this.
The text was updated successfully, but these errors were encountered: