-
Notifications
You must be signed in to change notification settings - Fork 36
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
Repeated "Request textDocument/codeAction failed" errors #247
Comments
Ran into a couple more errors:
|
Experiments on: MAC: VSCode v1.78.1 Pack1: I am able to recreate the issue only with following:
Pack2: I am NOT able to recreate with following dependency:
|
For this error in the "Language Support for Jakarta EE" log....
...There is a corresponding exception in the "Language Support for Java" log. On initial glance, it looks like there are multiple issues here, but definitely looks like an NPE is occurring due to the CodeActionHandler in the org.eclipse.lsp4jakarta.jdt component.
|
If the reference above to |
Based on my experience with these errors, I do not yet see how they would be related to LemMinX or the LCLS. They seem purely related to LSP4Jakarta. On that note, this fix in LSP4Jakarta: eclipse/lsp4jakarta#450 appears to resolve the NPE codeAction failure. Other codeAction failures are still observed. |
As part of investigation found new issue with jakarta -> eclipse/lsp4jakarta#451 |
After applying changes made vai eclipse/lsp4jakarta#450 i am not getting NullPointerException. But i do see codeaction failure. Investigating further. From Vscode side i don't find much of help from developer tools. Trying to add debug with lsp4jakarta code to check further. Following 2 errors are most common:
But as per my observation code completion action not affected. But we do see lot of above errors. This is very common in windows. Very rare in MAC system. |
@dshimo is going to investigate what options there are for suppressing these errors from LSP4Jakarta in VS Code, as they appear to be mostly benign. |
Also note that while @rumanaHaque was able to reproduce the codeAction failures on her Mac machine, @dshimo was not able to reproduce it on his Mac. He also was not able to reproduce on his Linux machine - we will try another Linux machine to see the behaviour there. Also, @scottkurz has not been able to reproduce these issues in Eclipse. |
Looking at trace from Language Support for Java - the actions seem valid. Below are trace statements pulled from the logs related to request 221:
Need to try to understand why the request is considered "failed" when it has been cancelled. Is this something caused on the LSP4Jakarta side or is it caused by the VS Code client? |
I was able to recreate the codeAction failure issue on both Windows (11) and RedHat Linux (9) |
Investigating changes to Also tried using a try/catch similar to RedHat's VS Code extension. Did not seem to work for our scenario. @dshimo is investigating possibly using a CancellationToken Another possible route is to use |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as resolved.
This comment was marked as resolved.
Updating
Other changes were made that may or may not be necessary (ie. using try/catch, using cancellationToken). Next plan of action is to test incremental changes to make sure we only use what we need. |
codeAction failure from cancelled request will be resolved by #255
NPE was resolved by eclipse/lsp4jakarta#450
Issue opened in LSP4Jakarta repo to address ClassCastException: eclipse/lsp4jakarta#455
Issue opened to address unmatched cancel notification: #256
|
When working in Java files while LSP4Jakarta is activated, attention is constantly pulled to the Output tab as there are repeated codeAction request failures. These errors do not appear to affect the language feature functionality, but they do pull the user's focus and repeatedly show up in the log.
Another version of the codeAction failure resulted in an NPE:
It was initially thought that the codeAction failures were related to the NPE in #227 (you can see the codeAction failures in the log for that issue) or the UnsupportedOperationException in #207, but it seems they may be an issue on their own. It is not clear if the root cause of the issue resides on the VS Code client side or on the language server side.
The text was updated successfully, but these errors were encountered: