OmniSharp / OmniSharp/csharp-language-server-protocol
CodeAction capability doesn't work with VS Code LSP client
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 638
- Forks
- 109
- Avg merge
- 1m
- Merged PRs (30d)
- 2
Description
I been trying to get textDocument/codeAction working with VS Code but it's impossible to get any call to that endpoint from vscode with a omnisharp LSP server using handlers. My handler is implementing ICodeActionHandler.
I dig a bit the issue and it seems to came from server capabilities that are not set correctly on the Initialize request.
LanguageServer.Handle method for the Initialize request is setting server capabilities based on received client capabilities https://github.com/OmniSharp/csharp-language-server-protocol/blob/4d53a6eccad0826b54d0fe206e5383643c525978/src/Server/LanguageServer.cs#L321
The GetStaticOptions will set the capability to false if the client capability support DynamicRegistration.
https://github.com/OmniSharp/csharp-language-server-protocol/blob/4d53a6eccad0826b54d0fe206e5383643c525978/src/Server/ClientCapabilityProvider.cs#L30
That will end up to send capabilities with a codeActionProvider to false to the client, which seems to be the source of the problem. Even if it supposed to dynamic registered VS Code seems to have to receive the codeActionProvider capability to true on initilialization in order to have the codeAction working. I verified my hypothesis by "hacking" the client request on the OnInitialize of my server to skip the dynamic registration thing:
var serverOptions = new LanguageServerOptions()
.WithInput(stream)
.WithOutput(stream)
.WithServices(ConfigureServices)
.WithHandler<TextDocumentHandler>()
.OnInitialize((server, request, token) =>
{
request.Capabilities.TextDocument.CodeAction.Value.DynamicRegistration = false;
return Task.CompletedTask;
});
and it's indeed working, and now I receive textDocument/codeAction events from vs code. This also seems to be documented on the vscode side: https://code.visualstudio.com/api/language-extensions/programmatic-language-features#possible-actions-on-errors-or-warnings (under Possible Actions on Errors or Warnings/Language Server Protocol)
Am I missing something about Omnisharp LSP server regarding the management of capabilities or is there an issue here? I always make it worked with just implemented the right interface on my handlers, and thought it was the way to go.
I'm using version 0.17.4, but I also had the issue on 0.15.0.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the Initialize handling in src/Server/LanguageServer.cs around the capability setup, then inspect GetStaticOptions in src/Server/ClientCapabilityProvider.cs. Reproduce with VS Code and an ICodeActionHandler, checking whether the initialize response advertises codeActionProvider and whether textDocument/codeAction reaches the handler. Done means the capability behavior matches the documented VS Code requirement without the request workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, backend-api-design
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100