Persistent container recreated in every test run

[cnshenj]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Container runtime: Podman 5.3.0

Debug the AppHost several times, then use podman ps to list containers - there is only one. This is expected and desired behavior.

Create an Aspire test project and uncomment the sample test. Run the test several times, then use podman ps to list containers. There is one container per test run, all in "up" state. For example, if I run the test 10 times, there will be 10 containers created and all in "up" state.

Expected Behavior

Only one persistent container created for any number of test runs.

Steps To Reproduce

builder.AddSqlServer("MySqlServer").WithLifetime(ContainerLifetime.Persistent).AddDatabase("MyDatabase");

Create an Aspire test project and uncomment the sample test. Run the test several times, then use podman ps to list containers.

Exceptions (if any)

No response

.NET Version info

.NET SDK:
Version: 9.0.101
Commit: eedb237549
Workload version: 9.0.100-manifests.4a280210
MSBuild version: 17.12.12+1cce77968

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

Project target framework: NET 8.0
Aspire version: 9.0

Anything else?

No response

[afscrome]

See #6850

[karolz-ms]

I believe DCP has everything app model needs to implement the desired behavior. In fact, the first thing I would try is for (test) app host stops applying a random suffix for the container. DCP already does that for both persistent and non-persistent containers, so there is no need for the app host to duplicate this.

The container reuse is by default determined by container (resource name + spec hash) combination. As long as name and spec has match, it will be reused. If a more coarse/custom reuse is desired, the Container.Spec has a LifecycleKey property that (if not empty) determines if a Docker/Podman container "matches" the Aspire Container resource (the name needs to match too).

[dansiegel]

I believe this seems to be part of the problem. You'll notice that as soon as we stop running the Aspire AppHost these services are losing their assigned ports. This results in constantly shifting ports and services being recreated even though they are meant to be persistent.