DocumentVersion shouldn't be reset to 0 when handling "textDocument/didSave"

[Swassie]

I'm using the LSP client Eglot in emacs together with OmniSharp, and it mostly works well. One problem I have encountered is triggered by the following sequence:

1. Edit a file. (Client increments the DocumentVersion).
2. Save the file. (Server resets the version to 0 internally).
3. Request and execute a code action for the file, e.g. add missing 'using ...'
4. Server requests "workspace/applyEdit" for the file, with version 0.
5. Client fails to apply the edit since the version doesn't match.

I think that OmniSharp shouldn't reset the version in this case. I have looked at a few of the other major LSP servers and I couldn't find anyone that did this. Also I did try removing the line src/OmniSharp.LanguageServerProtocol/Handlers/OmniSharpTextDocumentSyncHandler.cs:158 and it solves the problem.

Thanks for your work!

[jameschensmith]

I'm running into this issue as well, and it's very annoying to have to restart the language server any time I want to do code actions (renames don't require a restart, though, which is nice 😅 ). I've dug into this a bit and would like to see if I can help bring traction to this issue.

• In the LSP specification for textDocument/didSave, there is no mention that the server should reset the version to 0.
• When looking at the blame of the line mentioned by @Swassie, it appears that this change was made almost 3 years ago by @razzmatazz in this commit.
• @razzmatazz, is working on his own C# language server. In his implementation of textDocument/didSave, there doesn't appear to be any document version resetting.

Based on this analysis, @razzmatazz, would you be able to help with any of the following:

1. Provide some history / context as to why a version reset was added to textDocument/didSave.
2. Would you be able to fix this in Roslyn if this is indeed a bug?