Repository navigation
Forward ValueProviderContext in Blazor GatewayOriginReference - #21452
James Newton-King (JamesNK) merged 2 commits into
Conversation
GatewayOriginReference only implemented the context-free GetValueAsync, so the IValueProvider default interface method dropped the ValueProviderContext. The gateway origin then resolved on the localhost network during deployment, which hangs when localhost is never allocated (Container Apps) or emits a localhost URL. Fixes #21067 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 -- 21452Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 21452" |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues are reported for the change preserving the requested network during gateway-origin resolution.
No open issues 🎉
What changed in this PR
Fixes #21067 by preserving the requested network when resolving Blazor gateway origins, preventing deployment hangs or localhost URLs in deployed client configuration.
Changes:
- Adds a context-aware
GatewayOriginReference.GetValueAsyncoverload that forwards the context while preserving trailing-slash trimming. - Adds regression tests for deployment-network resolution both with and without a localhost allocation.
| File | Description |
|---|---|
tests/Aspire.Hosting.Blazor.Tests/GatewayConfigurationBuilderTests.cs |
Tests that generated client configuration uses the requested network. |
src/Aspire.Hosting.Blazor/GatewayOriginReference.cs |
Forwards ValueProviderContext to the underlying endpoint. |
Review effort: Balanced
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
# Conflicts: # tests/Aspire.Hosting.Blazor.Tests/GatewayConfigurationBuilderTests.cs
Tests selector3 / 100 PR test projects · 3 PR jobs, from 2 changed files. Selected PR test projects (3 / 100)
Selected PR jobs (3)
How these were chosen — grouped by what changed🔧 📦 affected project 🧪 Job reasons
Selection computed for commit |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Merged On the new head, two Windows VS Code extension E2E jobs failed ( 🤖 Posted by AspireAgent (AI Agent) |
|
✅ No documentation update needed. docs_optional → bug_fix_restores_documented_behavior. No signals triggered (signal_count == 0). The PR forwards ValueProviderContext in the Blazor GatewayOriginReference so the gateway origin resolves on the requested network during deployment. It fixes an internal hang and a localhost leak, and adds no new public surface, options or strings. |
Description
Fixes #21067
When a Blazor WebAssembly app is hosted behind a gateway and deployed (for example to Azure Container Apps), the gateway origin used in the client configuration was resolved on the localhost network instead of the network requested by the deployment. As a result, deployment hung forever when localhost was never allocated (the reported Container Apps hang). When localhost was allocated, the localhost URL leaked into the deployed configuration.
Root cause
IValueProviderhas a default interface methodGetValueAsync(ValueProviderContext, CancellationToken)that falls back toGetValueAsync(CancellationToken), which discards the context.GatewayOriginReferenceonly implemented the context-free overload.ReferenceExpression.GetValueAsync(context)forwards theNetworkIdentifierto its value providers, but here the network was dropped. The wrappedEndpointReferencethen waited for a localhost allocation, either forever or until it resolved to a localhost URL.Fix
GatewayOriginReferencenow implements the context-aware overload and forwards the context toEndpointReference.GetValueAsync(context, ...), which already supports it. The trailing-slash trimming is unchanged. The context-free path is untouched.Regression tests
Two new tests in
GatewayConfigurationBuilderTestsresolve the expression fromBuildConfigExpressionwith aValueProviderContextthat targets a non-localhost network:BuildConfigExpression_ResolvesOriginOnRequestedNetwork_WithoutLocalhostAllocationallocates the endpoint only on the requested network. This matches the reported hang; a 10sWaitAsyncguard turns the hang into a failure.BuildConfigExpression_ResolvesOriginOnRequestedNetwork_WhenLocalhostIsAlsoAllocatedalso allocates localhost and asserts that the requested-network origin is used and nolocalhostappears.main(a76b57a)..._WithoutLocalhostAllocationTimeoutException(hang)..._WhenLocalhostIsAlsoAllocatedAssert.Contains()failure: localhost URL substitutedNon-Docker
Aspire.Hosting.Blazor.Testsclasses, run locally with the fix: 96/97 pass.BlazorHostedExtensionsTests.ProxyService_WhenClientDiscoveryFails_SurfacesFailure. It fails identically on unmodifiedmainin my environment, so it's environmental and unrelated.AddBlazorGatewayTestspublish tests couldn't run locally, because there was no network access to download the SDK inside containers. CI covers them.Checklist
🤖 Posted by AspireAgent (AI Agent)