Exe and Container reaching Exit Code 0 have different terminal states for the same result.

[afscrome]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

If you have a container that exists with exit code 0 (Think of a Kubernetes job that runs to completion successfully), aspire reports this as Exited and shows up as a warning. When an executable does the same thing, it instead goes to neutral state.

Similarly for a container with an exit code, it ends up in the Exited state whilst an executable ends up in the Finished state

Expected Behavior

I'd expect the two Green highlighted fields to be in the same Finished state with a neutral icon. I'd expect the two blue highlighted fields to end up in the same Finished state with an error icon.

Steps To Reproduce

var successExe = builder.AddExecutable("successExe", "pwsh.exe", ".")
    .WithArgs("-Command", "Write-Host Success");
var failExe = builder.AddExecutable("failExe", "pwsh.exe", ".")
    .WithArgs("-Command", "throw fail");

var successContainer = builder.AddContainer("successContainer", "mcr.microsoft.com/powershell")
    .WithArgs("pwsh", "-Command", "Write-Host Success");
var failContainer = builder.AddContainer("failContainer", "mcr.microsoft.com/powershell")
    .WithArgs("pwsh", "-Command", "throw Fail");

Exceptions (if any)

No response

.NET Version info

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.c6f19616
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.12.35514.174
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  6.0.428 [C:\Program Files\dotnet\sdk]
  8.0.404 [C:\Program Files\dotnet\sdk]
  9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

Anything else?

		<Sdk Name="Aspire.AppHost.Sdk" Version="9.0.0" />
		<PackageReference Include="Aspire.Hosting.AppHost" Version="9.0.0" />

[adamint]

I went down the history for this change and it didn't unearth any explanatory information why Finished and Exited are treated differently other than that they are different resource types. @JamesNK should they be treated the same?

[adamint]

This behavior is wholly within the dashboard code

[joperezr]

Thanks for logging this @afscrome. The difference in icon is a matter of return code, and it's already tracked by #6569. In terms of the state, resource types control their own states so we can take a look at why we have a difference here and find if there is something to fix.