[release/13.4] Use KnownConfigNames for resource service endpoint URL with legacy fallback#17571
Conversation
…llback Remove hardcoded DOTNET_RESOURCE_SERVICE_ENDPOINT_URL constant from DashboardServiceHost and use KnownConfigNames.ResourceServiceEndpointUrl (ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL) with fallback to KnownConfigNames.Legacy.ResourceServiceEndpointUrl.
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17571Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17571" |
|
❌ CLI E2E Tests failed — 105 passed, 2 failed, 2 unknown (commit ❌ Failed Tests
View all recordings
📹 Recordings uploaded automatically from CI run #26548483091 |
|
✅ No documentation update needed. docs_optional → No gating signals triggered (
Since the fix brings the implementation into line with documented behavior (not changing the documented interface), no docs update is needed. |
Backport of #17385 to release/13.4
/cc @JamesNK
Customer Impact
ASPIRE_RESOURCE_SERVICE_ENDPOINT_URLwas never used. Instead a random URL is chosen. A customer could specify the port they want to use, but it's never used.One impact of this change is some customers might go into a broken state because of bad configuration that was never used before. For example, they have the same
ASPIRE_RESOURCE_SERVICE_ENDPOINT_URLvalue used by multiple app hosts, and they're run at the same time, then they'll get an error that port is in use. They'll need to change the config value.Testing
E2E and unit tests
Risk
Low
Regression?
Yes, but many releases ago.