[release/13.4] Fix Redis persistent lifetime startup#17850
Conversation
Use Redis endpoint target ports for TLS startup arguments so container command-line evaluation does not wait for allocated public ports before the container exists. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Use a bounded wait around the Redis argument evaluation regression test so the test fails promptly if endpoint resolution deadlocks again. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17850Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17850" |
|
❓ CLI E2E Tests unknown — 110 passed, 0 failed, 2 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26846649775 |
|
✅ No documentation update needed. docs_optional → No signals triggered (signal_count = 0). The PR is a backport bug fix that changes two lines in |
Backport of #17827 to release/13.4
/cc @danegsta
Customer Impact
We were setting the standard (and TLS) ports for Redis based on the public container ports instead of the internal target ports. This could lead to Redis listening on an unexpected port and no longer be reachable when a user sets a specific public port that doesn't match the internal port.
Testing
Smoke tests and new unit tests
Risk
Low
Regression?
Not in 13.4 - this has been broken for at least one release but we just didn't realize it until another bug uncovered it.