avoid race condition on worker disposal #485
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Disposing of Kusto Worker on
setLanguageSettings
CallEvery time
setLanguageSettings
is called, the old Kusto worker is disposed of, and a new one is created. This means that if the old worker is in the middle of handling requests, those requests will be terminated before completion.What This Causes
We register the semantic token provider after
worker.setSchema
has completed. SincesetLanguageSettings
is called when entering the query page editor, the worker gets disposed of during that call, leaving thesetSchema
promise unresolved. As a result, the semantic tokens provider is not registered.The Workaround Solution
The solution is a bit of a workaround—apologies for that. I wait for 5 seconds before disposing of the old worker to allow it to finish processing previous requests. Before that, I reset the
workerManager
private member ofworkerDetails
, so new requests will create a new worker and be applied to the new instance.Is Disposing the Old Worker Necessary?
I did consider whether disposing of the old worker when
setLanguageSettings
is called is truly necessary. I believe it isn’t. However, Noam and I decided not to remove this behavior currently because it might impact unknown scenarios that we cannot easily test. Therefore, this change is not suitable when a Quick Fix Engineering (QFE) is required.