Clean up LSP message tests #1700
Conversation
andyleejordan
force-pushed
the
andschwa/lsp-tests
branch
from
6891eb5 to
4184362
Compare
| { | ||
| throw new Exception("Launch response was null."); | ||
| } | ||
|
|
||
| // This will check to see if we received the Initialized event from the server. | ||
| await Task.Run( | ||
| async () => await started.Task.ConfigureAwait(false), | ||
| new CancellationTokenSource(2000).Token).ConfigureAwait(false); | ||
| async () => await started.Task.ConfigureAwait(true), |
There was a problem hiding this comment.
since you're changing the behavior of the ConfigureAwait consider a comment to explain why the advice of https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.configureawait?view=net-6.0#remarks isn't applicable.
There was a problem hiding this comment.
Ah! Truly what I need to document is like in a developer's guide for PSES. Essentially, at the library level (any PSES code itself) we must disable the continue on captured context (i.e. false) otherwise we deadlock when users import things like System.Windows.Forms that start their own thread context. The library has to be setup to not care which it's on and so continue executing. At the "app" level (e.g. tests) we actually want it set to true (also the default, but I setup a compiler rule to enforce that .ConfigureAwait be called) because xUnit introduces its own thread context, and we run into deadlocks with tests because the test code (like UI/app code) needs to only continuing executing where it left off, otherwise it can cause the test to end up on the PSES pipeline thread.
So my rule for the codebase (which is documented in a couple places, but you're right it needs to be either in more or at a higher level) is: ConfigureAwait(false) in PSES code, ConfigureAwait(true) in test code. The latter won't always break things, and our initial run through when I enabled that compiler rule was to set everything to false, hence they're all false right now but as I'm cleaning up tests I'm fixing it. I should do a single PR fixing all the test code.
| PwshExe = PsesStdioProcess.PwshExe; | ||
| } | ||
|
|
||
| public void Dispose() | ||
| { | ||
| Diagnostics.Clear(); | ||
| TelemetryEvents.Clear(); | ||
| GC.SuppressFinalize(this); |
There was a problem hiding this comment.
Should this ever run on a finalizer thread? Is there a class destructor to finalize? Just wondering if this is needed.
There was a problem hiding this comment.
I had a long conversation with Dongbo to learn all about this and while this doesn't cause a bug, the compiler barfs a warning about it, and this is the "correct" fix. If this were product code it would be more important, but I'm working to just get us to a zero-warning codebase. Slowly, but surely.
Just applying automatic cleanups.