Derive Azure Front Door origin names from backend hostnames - #20035
Conversation
Include the backend hostname and resource group in the origin name hash so changing compute backends creates a distinct origin. Respect SDK name requirements and update the Bicep snapshots. Co-authored-by: Copilot App <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 -- 20035Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20035" |
github-actions
Bot
added
the
area-integrations
Tests selector2 / 99 PR test projects · 2 PR jobs · 1 advisory-only target, from 3 changed files. Selected PR test projects (2 / 99)
Selected PR jobs (2)
Advisory workflow impact (1)
How these were chosen — grouped by what changed🧪 🔧 🧪 Job reasons
Selection computed for commit |
There was a problem hiding this comment.
🟡 Changes recommended
Incremental deployments retain the old origin in the unchanged origin group, potentially continuing to route traffic to the previous backend.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Updates Azure Front Door origin naming so backend hostname changes produce distinct Azure origin identities.
Changes:
- Adds backend hostname to the origin-name hash.
- Uses Azure’s origin-name length limit.
- Updates single- and multiple-origin Bicep snapshots.
File summaries
| File | Description |
|---|---|
src/Aspire.Hosting.Azure.FrontDoor/AzureFrontDoorExtensions.cs |
Revises generated origin names. |
tests/...SingleOriginGeneratesBicep.verified.bicep |
Updates single-origin snapshot. |
tests/...MultipleOriginsGeneratesBicep.verified.bicep |
Updates multiple-origin snapshot. |
Review details
Suppressed comments (1)
src/Aspire.Hosting.Azure.FrontDoor/AzureFrontDoorExtensions.cs:134
- This does not safely switch the backend during a redeployment. Aspire submits these templates with
ArmDeploymentMode.Incremental, so the previous physical origin is retained when this hash produces a new name. Because the origin-group name stays unchanged and the route targets that group, both the old and new origins remain members; Front Door can continue probing and routing traffic to the old backend. Include the hostname-derived identity in the origin group and repoint the route, or explicitly remove the obsolete origin as part of deployment.
origin.Name = BicepFunction.Take(
BicepFunction.Interpolate($"{originBicepId.Replace('_', '-')}Origin-{BicepFunction.GetUniqueString(BicepFunction.GetResourceGroup().Id, hostParam)}"),
origin.GetResourceNameRequirements().MaxLength);
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Balanced
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
Eric Erhardt (eerhardt)
added
the
breaking-change
|
Pull request created: #1646
|
|
📝 Documentation has been drafted in microsoft/aspire.dev#1646 targeting Updated the Azure Front Door integration doc and the Aspire 13.6 "What's new" page to cover the origin-naming breaking change:
Note This draft PR needs human review before merging. |
|
The CI build failed due to test failure(s) that appear unrelated to the PR changes. These may be flaky tests. Suspected flaky test(s): Suggested actions:
You can re-run the failed jobs from the workflow run page. |
Description
Azure Front Door origins currently retain the same Azure name when an Aspire compute resource resolves to a different backend hostname between deployments. Include the hostname in the origin's name so switching backends creates a distinct origin instead of reusing the existing origin's Azure identity.
Combine the resource-group ID and hostname in a single
uniqueStringsuffix, retain a readable resource-based prefix, and useFrontDoorOrigin.GetResourceNameRequirements().MaxLengthfor the name limit. Add a production comment explaining the rationale and update the single- and multiple-origin Bicep snapshots.Endpoint, origin-group, and route names remain unchanged. Existing deployments receive new origin names the first time this naming scheme is applied.
Examples
AppHost configuration is unchanged:
Generated origin name before:
Generated origin name after:
Breaking changes
This is a breaking deployment change for existing users of the Azure Front Door integration, even though the integration is still in preview. Upgrading changes origin resource names even when the backend hostname has not changed. Incremental ARM deployments do not remove resources omitted from the new template, so existing origins can remain alongside the newly named origins in the same origin group.
To preserve the previous default origin names, override them with
ConfigureInfrastructurebefore the first deployment after upgrading:The callback runs after the integration's defaults and applies to every configured origin. Removing underscores, rather than replacing them with hyphens, preserves the old prefix exactly: for example,
my_apiOriginbecomesmyapiOrigin.This override opts out of hostname-based origin identity changes. If the new naming scheme has already been deployed, applying the override does not delete the newly created origins; disable or remove the unwanted origins separately after confirming which origins should serve traffic. Users keeping the new naming scheme likewise need to account for cleanup of origins left behind by incremental deployments.
Validation
All 13
AzureFrontDoorTestspassed, including the updated Bicep snapshots. Quarantined and outerloop tests were excluded.Fixes # (issue)
Checklist
<remarks />and<code />elements on your triple slash comments?