Skip to content

Clean up LSP message tests #1700

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Feb 10, 2022
Merged

Clean up LSP message tests #1700

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 11 additions & 10 deletions test/PowerShellEditorServices.Test.E2E/DebugAdapterClientExtensions.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,23 +14,24 @@ public static class DebugAdapterClientExtensions
{
public static async Task LaunchScript(this DebugAdapterClient debugAdapterClient, string filePath, TaskCompletionSource<object> started)
{
LaunchResponse launchResponse = await debugAdapterClient.Launch(new PsesLaunchRequestArguments
{
NoDebug = false,
Script = filePath,
Cwd = "",
CreateTemporaryIntegratedConsole = false,
}).ConfigureAwait(false);
LaunchResponse launchResponse = await debugAdapterClient.Launch(
new PsesLaunchRequestArguments
{
NoDebug = false,
Script = filePath,
Cwd = "",
CreateTemporaryIntegratedConsole = false
}).ConfigureAwait(true);

if (launchResponse == null)
if (launchResponse is null)
{
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),
Copy link

Choose a reason for hiding this comment

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

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

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.

new CancellationTokenSource(2000).Token).ConfigureAwait(true);
}
}
}
Loading