Skip to content
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

Resolve a concurrency bug that could cause the IDE server not to send updates for a particular version #5299

Conversation

keyboardDrummer
Copy link
Member

@keyboardDrummer keyboardDrummer commented Apr 5, 2024

Description

  • Resolve a concurrency bug that could cause the IDE server not to send updates. From the data I have, my theory is that this was caused by UpdateDocument setting latestIdeState with an updated version, as it should, but after that an old compilation would also set latestIdeState with an old version, and the new compilation would pick up this old version and keep using it. The notification publisher would then not send any updates because it would consider them to be for an old version. The old compilation being able to set latestIdeState when it should not was caused by a call to observerSubscription.Dispose(); being done too late, and this PR resolves that.
  • Refactor UpdateDocument and StartNewCompilation so they are easier to read.

How has this been tested?

I don't know how to reproduce the issue, but this PR should greatly reduce the amount of random test failures. We could rerun the XUnit tests on this PR a few times to get more confidence.

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

…ate IdeStates with an old version, because between a call to DocumentUpdate and StartNewCompilation, latestIdeState was set by an old compilation
Copy link
Member

@MikaelMayer MikaelMayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that work, I'll be very very happy.
You might indeed try to perform multiple test runs to verify it's stabilizing the brittleness.

@@ -47,6 +46,7 @@ public record IdeState(
ImmutableDictionary<Uri, DocumentVerificationTree> VerificationTrees
) {
public Uri Uri => Input.Uri.ToUri();
public int Version => Input.Version;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is Input.Version mutable? If so, this might cause concurrency issues. I think you already realized that the more immutable, the less concurrency issues.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not mutable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants