Just ran into this as part of a rewrite of our Eclipse lsp4e-based plugin so that it more closely mirrors our VSCode offering. We switched over to using dynamic registration in our language server and I've just hit an awkward side effect:
we support code actions + (newly) dynamic registration
We don't support codeAction/resolve as we don't need it. This wasn't a problem with static registration, as we didn't populate CodeActionOptions.resolveProvider. However with dynamic registration, the detailed payload is ignored and LanguageServerWrapper just sets true (the left side of the boolean | CodeActionOptions union in the server capabilities).
|
serverCapabilities.setCodeActionProvider(Boolean.TRUE); |
Then when CodeActionMarker.run executes, if the action doesn't have an edit, it calls CodeActionCompletionProposal.isCodeActionResolveSupported() -
|
static boolean isCodeActionResolveSupported(@Nullable ServerCapabilities capabilities) { |
Because this only has the blanket true that the dynamic registration logic has stored, this also evaluates to true, so it then tries to call the unsupported codeAction/resolve method on our language server, which falls over...
Any thoughts on this? Looking at the rest of the dynamic registration code, is there any reason not to just unserialise the payload and store it in the server capabilities? The existing code seems to be a mixture - for some capabilities we unserialise the full payload and use it in its entirety, and for others we just register a yes/no capability. I'm assuming that this is mostly because there wasn't any demand for fuller support and so it just never needed to be implemented, rather than any technical limitation (e.g. problems unserialising)? If so, I could presumably submit a small patch that enhances what's there currently with an appropriate test?
Thanks
Just ran into this as part of a rewrite of our Eclipse lsp4e-based plugin so that it more closely mirrors our VSCode offering. We switched over to using dynamic registration in our language server and I've just hit an awkward side effect:
we support code actions + (newly) dynamic registration
We don't support
codeAction/resolveas we don't need it. This wasn't a problem with static registration, as we didn't populateCodeActionOptions.resolveProvider. However with dynamic registration, the detailed payload is ignored andLanguageServerWrapperjust setstrue(the left side of theboolean | CodeActionOptionsunion in the server capabilities).lsp4e/org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java
Line 1221 in 06a95f2
Then when
CodeActionMarker.runexecutes, if the action doesn't have an edit, it callsCodeActionCompletionProposal.isCodeActionResolveSupported()-lsp4e/org.eclipse.lsp4e/src/org/eclipse/lsp4e/operations/codeactions/CodeActionCompletionProposal.java
Line 49 in 06a95f2
Because this only has the blanket
truethat the dynamic registration logic has stored, this also evaluates to true, so it then tries to call the unsupportedcodeAction/resolvemethod on our language server, which falls over...Any thoughts on this? Looking at the rest of the dynamic registration code, is there any reason not to just unserialise the payload and store it in the server capabilities? The existing code seems to be a mixture - for some capabilities we unserialise the full payload and use it in its entirety, and for others we just register a yes/no capability. I'm assuming that this is mostly because there wasn't any demand for fuller support and so it just never needed to be implemented, rather than any technical limitation (e.g. problems unserialising)? If so, I could presumably submit a small patch that enhances what's there currently with an appropriate test?
Thanks