Redis integration fails to start container when lifetime is set to persistant

[TheOneHoff]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using the Redis hosting package (Aspire.Hosting.Redis) on v13.4.0, and using the extension method .WithLifetime(ContainerLifetime.Persistent), aspire fails to start a new Redis container or connect to an existing container.

Expected Behavior

When setting the container lifetime to be persistent, aspire should create a Redis container if one is not already running, and if a container that matches the configuration is running, it should connect to that container

This behavior works correctly in v13.3.5

Steps To Reproduce

1. Install the dotnet CLI
2. Clone the repo https://github.com/TheOneHoff/aspire-redis-lifetime-regression
3. Run the project using dotnet run or aspire start
4. Open the Aspire dashboard
5. Observe that the container does not start (logs: Waiting for endpoint 'tcp' on resource 'redis')

Downgrading the packages to v13.3.5 executes the expected behavior.

Exceptions (if any)

logs:
Waiting for endpoint 'tcp' on resource 'redis' for the '(null)' network

Aspire doctor output

{
"checks": [
{
"category": "aspire",
"name": "cli-version",
"status": "pass",
"message": "Aspire CLI version 13.4.0 (channel: stable)",
"metadata": {
"currentVersion": "13.4.0",
"identityChannel": "stable"
}
},
{
"category": "apphost",
"name": "apphost-version",
"status": "pass",
"message": "AppHost version 13.4.0 (RedisTest.csproj)",
"metadata": {
"appHostPath": "RedisTest.csproj",
"version": "13.4.0"
}
},
{
"category": "sdk",
"name": "dotnet-sdk",
"status": "pass",
"message": ".NET 10.0.300 installed (x64)"
},
{
"category": "environment",
"name": "dev-certs",
"status": "pass",
"message": "HTTPS development certificate is trusted",
"metadata": {
"certificates": [
{
"thumbprint": "4CB8A9D6D56B8C10A3EF868A962F3734F5C112E7",
"version": 6,
"trustLevel": "full",
"notBefore": "2026-04-10T14:43:25.0000000+08:00",
"notAfter": "2027-04-10T14:43:25.0000000+08:00"
}
]
}
},
{
"category": "container",
"name": "docker",
"status": "pass",
"message": "Docker v29.5.2: running (auto-detected (default)) ← active"
}
],
"summary": {
"passed": 5,
"warnings": 0,
"failed": 0
},
"installations": [
{
"path": "C:\Users\\.aspire\bin\aspire.exe",
"canonicalPath": "C:\Users\\.aspire\bin\aspire.exe",
"version": "13.4.0+becb48e2d61099e35ae336d527d3875e928d6594",
"channel": "stable",
"route": "script",
"pathStatus": "active",
"status": "ok"
},
{
"path": "C:\Users\\.dotnet\tools\aspire.EXE",
"canonicalPath": "C:\Users\\.dotnet\tools\aspire.EXE",
"pathStatus": "shadowed",
"status": "notProbed",
"statusReason": "No install-route sidecar found at C:\Users\\.dotnet\tools\.aspire-install.json; peer was not probed."
}
]
}

Anything else?

.NET Core Version: 10.0
dotnet CLI version: 10.0.300
aspire CLI version: 13.4.0

[JohnGalt1717]

This is a blocker. Any chance a quick turnaround on a .1 release?

[danegsta]

A fix for the general cause of this issue (as well as a specific Redis port allocation issue when HTTPS is enabled) has been released; you'll want to update to 13.4.2 to pickup both.