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

Only push output device messages to Test Explorer, don't push logs #4178

Open
wants to merge 29 commits into
base: main
Choose a base branch
from

Conversation

Youssef1313
Copy link
Member

@Youssef1313 Youssef1313 commented Nov 27, 2024

Logs are intended to be used for diagnosing. They shouldn't be localized and they shouldn't be pushed to Test Explorer.

Fixes #4213

Linked to AB#2275339

Logs are intended to be used for diagnosing. They shouldn't be localized and they shouldn't be pushed to Test Explorer.
Copy link
Member

@Evangelink Evangelink left a comment

Choose a reason for hiding this comment

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

Let's add a test where we have a fake adapter that emits the various messages and check we catch them with the right level.

break;
}
}
}

public Task DisplayBannerAsync(string? bannerMessage) => Task.CompletedTask;
Copy link
Member

Choose a reason for hiding this comment

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

Let's handle this case and print as debug.

@MarcoRossignoli @drognanar it feels like it would be too verbose to print as Info for TE but maybe we still prefer doing it. WDYT?

break;
}
}
}

public Task DisplayBannerAsync(string? bannerMessage) => Task.CompletedTask;

public Task DisplayBeforeSessionStartAsync() => Task.CompletedTask;
Copy link
Member

Choose a reason for hiding this comment

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

Let's emit a debug message here and when in trace we should emit a localized message with the path to the log file to help users looking up the log.

@Evangelink Evangelink marked this pull request as ready for review November 29, 2024 16:09
@@ -450,13 +444,20 @@ private async Task<ResponseArgsBase> ExecuteRequestAsync(RequestArgsBase args, s

DateTimeOffset adapterLoadStart = _clock.UtcNow;

IPlatformOutputDevice outputDevice = ServiceProvider.GetRequiredService<IPlatformOutputDevice>();
// TODO: What if some one wants to have their own output device that's also compatible with server mode in IDE?
Copy link
Contributor

@MarcoRossignoli MarcoRossignoli Nov 30, 2024

Choose a reason for hiding this comment

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

I think here we need to do something better.

Despite IPlatformOutputDevice is a bit special and the implementation needs to take into account more scenario(like app restart and correct handling for the "output") I'd like to abstract it from the "modes".

IPlatformOutputDevice implements IOutputDevice and today we pass to the IOutputDevice requestors the IPlatformOutputDevice implementation as-is.

Clearly this is not more good if we need to route display info due to modes.

So we should when IOutputDevice is requested from an extension to proxy it to be able to forward to the IPlatformOutputDevice but also to other internal part of the platform that needs it, for instance the server mode.

High level idea

 GetService<IOutputDevice>() -> OutputDeviceRouter -> ArbitraryPlatformOutputDeviceImplementation & ServerModeForwarder

In this way we don't need special or custom output device implementation for old and possible new modes and we can keep the "current" output device choice.

We cannot forward the ArbitraryPlatformOutputDeviceImplementation display..but I would expect that the info printed by the "device" are not important...the device output goal is to "show information" in "some way" it doesn't affect and should not affect in any way the execution, so information produced by this extension shouldn't be so useful.

cc: @Evangelink

Copy link
Contributor

@MarcoRossignoli MarcoRossignoli left a comment

Choose a reason for hiding this comment

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

I think we need another round of analysis on this one

@microsoft-github-policy-service microsoft-github-policy-service bot added Area: Server Mode Area: Testing Platform Belongs to the Microsoft.Testing.Platform core library labels Dec 2, 2024
@Evangelink
Copy link
Member

/azp run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).


// Looks like nothing in this message to really be localized?
// All are class names, method names, property names, and placeholders. So none is localizable?
await ServiceProvider.GetOutputDevice().DisplayAsync(
Copy link
Contributor

Choose a reason for hiding this comment

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

I think that use the GetAwaiter().GetResult() is better here. I don't expect a log of call here and awaiting a void we could lose the message.

@@ -15,15 +16,15 @@ public void SetPlatformOutputDevice(Func<IServiceProvider, IPlatformOutputDevice
_platformOutputDeviceFactory = platformOutputDeviceFactory;
}

public IPlatformOutputDevice Build(ServiceProvider serviceProvider)
internal ProxyPlatformOutputDevice Build(ServiceProvider serviceProvider, bool useServerModeOutputDevice)
Copy link
Contributor

Choose a reason for hiding this comment

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

why internal ctor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Localization Area: Server Mode Area: Testing Platform Belongs to the Microsoft.Testing.Platform core library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Output messages should be forward to clients instead of logs (server mode)
3 participants