Description
Follow-up to #17005 which centralized CLI log path display on non-zero exit codes.
When the CLI connects to an already-running app host (e.g., aspire resource, aspire describe, aspire stop, aspire logs, etc.), it should also print the log path of the CLI process managing that app host. This helps users diagnose issues in the managing CLI process, not just the current CLI invocation.
Today, when the child CLI process launches an app host via aspire run, it passes ASPIRE_CLI_PID and ASPIRE_CLI_STARTED as environment variables so the app host knows which CLI process launched it. However, the child CLI's log file path is not communicated, so querying CLI processes (e.g., aspire resource) have no way to surface it.
Proposed Changes
-
Add ASPIRE_CLI_LOG_FILE environment variable — Add a CliLogFilePath constant to KnownConfigNames. Set it alongside ASPIRE_CLI_PID in DotNetCliRunner, PrebuiltAppHostServer, and DotNetBasedAppHostServerProject when launching the app host.
-
Add CliLogFilePath to backchannel data types — Add the property to AppHostInformation and GetAppHostInfoResponse in BackchannelDataTypes.cs. Populate it in AuxiliaryBackchannelRpcTarget.GetAppHostInfoAsync() by reading from configuration.
-
Surface in AppHostConnectionResolver — After resolving a connection, if AppHostInfo.CliLogFilePath is set, store it on CliExecutionContext.AppHostCliLogFilePath (new property).
-
Display in BaseCommand — In DisplayLogPathOnFailure, if ExecutionContext.AppHostCliLogFilePath is set, print it in addition to the current CLI's log path. May need a new localized string (e.g., SeeAppHostLogsAt) to differentiate.
See CLI logs at XXXX
See AppHost logs at XXXX
Commands That Would Benefit
All commands using AppHostConnectionResolver:
aspire resourceaspire describeaspire stopaspire logsaspire waitaspire exportaspire telemetry logs/spans/tracesaspire mcp call/tools
Description
Follow-up to #17005 which centralized CLI log path display on non-zero exit codes.
When the CLI connects to an already-running app host (e.g.,
aspire resource,aspire describe,aspire stop,aspire logs, etc.), it should also print the log path of the CLI process managing that app host. This helps users diagnose issues in the managing CLI process, not just the current CLI invocation.Today, when the child CLI process launches an app host via
aspire run, it passesASPIRE_CLI_PIDandASPIRE_CLI_STARTEDas environment variables so the app host knows which CLI process launched it. However, the child CLI's log file path is not communicated, so querying CLI processes (e.g.,aspire resource) have no way to surface it.Proposed Changes
Add
ASPIRE_CLI_LOG_FILEenvironment variable — Add aCliLogFilePathconstant toKnownConfigNames. Set it alongsideASPIRE_CLI_PIDinDotNetCliRunner,PrebuiltAppHostServer, andDotNetBasedAppHostServerProjectwhen launching the app host.Add
CliLogFilePathto backchannel data types — Add the property toAppHostInformationandGetAppHostInfoResponseinBackchannelDataTypes.cs. Populate it inAuxiliaryBackchannelRpcTarget.GetAppHostInfoAsync()by reading from configuration.Surface in
AppHostConnectionResolver— After resolving a connection, ifAppHostInfo.CliLogFilePathis set, store it onCliExecutionContext.AppHostCliLogFilePath(new property).Display in
BaseCommand— InDisplayLogPathOnFailure, ifExecutionContext.AppHostCliLogFilePathis set, print it in addition to the current CLI's log path. May need a new localized string (e.g.,SeeAppHostLogsAt) to differentiate.Commands That Would Benefit
All commands using
AppHostConnectionResolver:aspire resourceaspire describeaspire stopaspire logsaspire waitaspire exportaspire telemetry logs/spans/tracesaspire mcp call/tools