-
Notifications
You must be signed in to change notification settings - Fork 199
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
Stop using VS buffer version numbers in the language server #9197
Labels
Milestone
Comments
Full log from an instance of this happening on my machine: RazorLog.txt |
It would seem the Roslyn side of this exception is tracked by this PRISM fault: https://prism.vsdata.io/failure/?eventType=Fault&failureHash=fb578b03-40b2-a3c3-8705-a482b78a0769 and this issue: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1841559 |
davidwengier
added a commit
that referenced
this issue
Oct 19, 2023
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1841559 while we wait for the real fix, either #9197 or The Great Merge™
Whoops, this was fixed by #10747 in 17.12 P2 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently in VS we use the version numbers from the VS text buffer to drive our language server version numbers. This falls down due to a race condition, and due to VS buffer version numbers only changing with literal buffer changes. What is actually happening sometimes is that sometimes we can produce two versions of the generated code, one without tag helper info, and one with, but both appear as "version 1" since the .razor file content doesn't change. This means that requests that go to Roslyn which should be waiting on v2 of the generated file, actually wait on v1, and therefore don't wait for synchronization because v1 has already been seen, it was just the wrong v1.
In theory we should be able to track version numbers inside our language server, independent of the client. If we can trust the client to send us didChange/didOpen/didClose correctly then we shouldn't lose any information, and we can add our own entropy in with DocumentChanged and/or ProjectChanged events when tag helpers are discovered etc.
See the log below. Note the two
UpdateCSharpBuffer
requests, both with version 1, but for different sets of changes. The secondsemanticTokens/range
request comes in and makes a request of Roslyn for the larger C# file, which the langauge server knows about, but as luck would have it Roslyn has not been updated yet. Our normal process to handle this, the document sync service, is not called because the version numbers are "seen".Worth noting this issue created by deduction based on looking at the log above, and the code in question. If my theory is correct it should be possible to reproduce this behaviour by opening a .razor file that uses a component, and opening the component .razor file itself, and then adding a
@namespace Goo
directive to the component. This should cause us to regenerate the first files generated code, requery semantic tokens etc. and the colour of the component should change, without a version number change.The error that appears in the log that illustrates this problem is:
The text was updated successfully, but these errors were encountered: