workspace/applyEdit with versioned TextDocumentEdit is not always rejected when document version has advanced

[LCamel]

Summary

When a language server sends a workspace/applyEdit containing a versioned TextDocumentEdit, the client sometimes applies the edit even though the local document version has already advanced past the version specified in the edit.

Steps to Reproduce

A minimal reproduction is available at:
LCamel/vscode-extension-samples @ repro/versioned-edit-bug

1. Open a plaintext file containing apple\nbanana
2. Press F11 — triggers a server-side workspace/applyEdit with a versioned TextDocumentEdit (replace chars 0–5 with XXXXX, using the document version captured at request time)
3. Immediately press Enter, advancing the document version before the edit arrives
4. Repeat a few times

Expected Behavior

Either of these two outcomes is correct depending on timing:

The edit arrives before the Enter (edit applied correctly):

XXXXX

banana

The Enter arrives before the edit (edit rejected correctly due to version mismatch):

apple
banana

Actual Behavior

The edit is intermittently applied in a way that produces an impossible document state — apple survives even though the edit was supposed to replace it:

XXXXX
apple
banana

Demonstration

https://www.youtube.com/watch?v=_zyFEwdu6OE

[dbaeumer]

I tried to reproduce this but failed. I watch the video though and saw it happen. I read through the current code and I couldn't find a reason why this can fail. I upgraded the example to the latest next version of the client and server library, however I can't push to the fork. @LCamel could you add me as a contributor so that I can push the changes. I would also like to ask you whether you can still reproduce this then.

[LCamel]

Thanks for looking into this! I've added you as a contributor.

[dbaeumer]

I push the update of the versions for the lsp-sample. Let me know if you an still reproduce.

[LCamel]

It is still reproducible.

https://youtu.be/C5JOGguTpso

[dbaeumer]

Thanks again. I did some more debugging and actual the problem is not in the LSP libraries. It is in VS Code itself.

[dbaeumer]

This is caused by microsoft/vscode#317275

@LCamel thanks a lot for reporting this and spending the time to reproduce.