Skip to content

NamedPipeServer callbacks do no async work. so make the signature sync#7507

Closed
SimonCropp wants to merge 1 commit intomicrosoft:mainfrom
SimonCropp:NamedPipeServer-callbacks-do-no-async-work.-so-make-the-signature-sync
Closed

NamedPipeServer callbacks do no async work. so make the signature sync#7507
SimonCropp wants to merge 1 commit intomicrosoft:mainfrom
SimonCropp:NamedPipeServer-callbacks-do-no-async-work.-so-make-the-signature-sync

Conversation

@SimonCropp
Copy link
Contributor

No description provided.

Copilot AI review requested due to automatic review settings March 8, 2026 08:06
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the NamedPipeServer request callback contract to be synchronous, removing unnecessary async/Task usage across the IPC stack (platform hosts, MSBuild task, extensions, and unit tests).

Changes:

  • Changed NamedPipeServer callback type from Func<IRequest, Task<IResponse>> to Func<IRequest, IResponse> and removed the await at the invocation site.
  • Updated all in-repo call sites (hosts, MSBuild task, extensions) and unit tests to provide synchronous callbacks returning IResponse directly.
  • Converted a few callback implementations that only performed async logging to use synchronous logging APIs.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file
File Description
test/UnitTests/Microsoft.Testing.Platform.UnitTests/IPC/IPCTests.cs Updates unit test callbacks to return IResponse synchronously.
src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs Changes the callback delegate type to synchronous and invokes it without await.
src/Platform/Microsoft.Testing.Platform/Hosts/TestHostControllersTestHost.cs Updates the IPC server callback handler to be synchronous.
src/Platform/Microsoft.Testing.Platform.MSBuild/Tasks/InvokeTestingPlatformTask.cs Updates MSBuild IPC server request handler to be synchronous.
src/Platform/Microsoft.Testing.Extensions.TrxReport/TrxProcessLifetimeHandler.cs Updates TRX extension IPC callback to be synchronous.
src/Platform/Microsoft.Testing.Extensions.Retry/RetryFailedTestsPipeServer.cs Updates retry extension IPC callback to be synchronous.
src/Platform/Microsoft.Testing.Extensions.HangDump/HangDumpProcessLifetimeHandler.cs Updates hang dump lifetime handler IPC callback to be synchronous and switches debug logging to sync.
src/Platform/Microsoft.Testing.Extensions.HangDump/HangDumpActivityIndicator.cs Updates hang dump activity indicator IPC callback to be synchronous and switches debug logging to sync.
Comments suppressed due to low confidence (1)

src/Platform/Microsoft.Testing.Platform/IPC/NamedPipeServer.cs:46

  • Changing NamedPipeServer's callback type from Func<IRequest, Task> to Func<IRequest, IResponse> is a binary breaking change for friend assemblies (the Platform project exposes internals to multiple Extensions projects). Given this file already keeps compatibility overloads to avoid MissingMethodException when core and extension packages are version-skewed, consider adding compatibility constructor overload(s) that still accept Func<IRequest, Task> and adapt internally, so older extensions can continue to load against a newer core.
    public NamedPipeServer(
        string name,
        Func<IRequest, IResponse> callback,
        IEnvironment environment,
        ILogger logger,
        ITask task,
        CancellationToken cancellationToken)

if (request is GetInProgressTestsRequest)
{
await _logger.LogDebugAsync($"Received '{nameof(GetInProgressTestsRequest)}'").ConfigureAwait(false);
_logger.LogDebug($"Received '{nameof(GetInProgressTestsRequest)}'");
Copy link
Member

Choose a reason for hiding this comment

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

This is potentially running on a threadpool thread, and the logger implementation is very likely synchronized via a semaphore. Waiting on the semaphore synchronously might lead to blocking threadpool thread in case there is some contention in logging, and I think this is a risky change to make.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

does that mean the sync log APIs should be removed? and all callers of them made async?

Copy link
Member

@Youssef1313 Youssef1313 Mar 8, 2026

Choose a reason for hiding this comment

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

I wouldn't say it should be removed, but we could revise usages to switch to async when it makes sense.

For example, if we are running something in a custom non-threadpool thread, the sync version makes sense, and (depending on the exact work done on that thread) might even be preferred over the async variant. But in other cases, the async version will make more sense (especially when it's something already running on a threadpool thread)

@SimonCropp SimonCropp closed this Mar 10, 2026
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.

3 participants