E2E Deployment Test Failure: Aspire.Deployment.EndToEnd.Tests.FrontDoorDeploymentTests.DeployReactTemplateWithFrontDoor

[mitchdenny]

Failing Test

Aspire.Deployment.EndToEnd.Tests.FrontDoorDeploymentTests.DeployReactTemplateWithFrontDoor

Symptom

The test consistently fails on every nightly Deployment E2E run with:

Hex1b.Automation.Hex1bAutomationException : Step 36 of 36 failed — WaitUntilText("(based on NuGet.config)")
Hex1b.Automation.WaitUntilTimeoutException : WaitUntil timed out after 00:01:00 waiting for: text "(based on NuGet.config)" to appear

The failure occurs at the first aspire add Aspire.Hosting.Azure.AppContainers invocation after creating the React starter project.

Root Cause

The test waits for the legacy (based on NuGet.config) version-selection prompt and then sends Enter:

https://github.com/microsoft/aspire/blob/main/tests/Aspire.Deployment.EndToEnd.Tests/FrontDoorDeploymentTests.cs#L99-L117

However, when a matching package is resolved from the local bundle (the common case in CI), aspire add no longer prompts for a version — it installs directly. The recorded terminal output for the failing run confirms this:

⠲ Adding Aspire hosting integration...
✅ The package Aspire.Hosting.Azure.AppContainers::13.4.0-dev was added successfully.
[6 OK] $

The 60-second wait for (based on NuGet.config) then times out.

Fix

Replace the explicit "wait-for-prompt + Enter" block with WaitForAspireAddCompletionAsync, which handles both the version-prompt and no-prompt code paths (the same pattern already used by AksAzureKubernetesEnvironmentCertManagerTypeScriptDeploymentTests).

Affected Runs

• https://github.com/microsoft/aspire/actions/runs/26323258106 (2026-05-23)
• https://github.com/microsoft/aspire/actions/runs/26268417397 (2026-05-22)
• https://github.com/microsoft/aspire/actions/runs/26205530633 (2026-05-21)
• ...and every prior nightly run going back several weeks.

This issue was created automatically by a workflow analyzing Deployment E2E test failures on main.

[joperezr]

🤖 Aspire triage pass — 2026-05-24 04:13 UTC

Area: area-deployment, area-testing, area-cli
Kind: test-failure
Repro: yes-minimal — body points at the exact WaitUntilText("(based on NuGet.config)") block (line range cited) and notes that aspire add no longer emits the legacy version-selection prompt when the package resolves from the local bundle. Proposed fix: switch to WaitForAspireAddCompletionAsync (pattern already used by the AKS TS deployment test).
Affected version(s): main / 13.4-dev — failure pattern reported on every nightly run going back several weeks (cited runs: 2026-05-21 → 2026-05-23 + "several weeks").
Severity: S3 — long-standing CI-only failure; product aspire add UX behaves as designed.

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: Mechanical Hex1b helper swap, no product change. Not a 13.3-vs-13.2 regression (it's a stale test wait pattern). Worth fixing in 13.4 because it has been masking real signal on Deployment E2E nightlies for weeks.

Suggested owner(s): triage:needs-human
Evidence:

• All area-deployment merges in the last 90d (Enable Gateway API and AGC in AddAzureKubernetesEnvironment #16990, Add first-class Kubernetes Ingress and Gateway API resources #16487, Add Azure Kubernetes Service (AKS) hosting support #16088, Fix Kubernetes publisher crash on Boolean/scalar environment variable values #15560) are by the issue author — excluded per Rule S4.
• CODEOWNERS lists @mitchdenny, @JamesNK, @davidfowl for src/Aspire.Cli/** and @radical, @eerhardt for tests/Aspire.EndToEnd.Tests/**, but none have a clean evidence-stream score after author exclusion.
• A human should pick between @JamesNK (CLI CODEOWNER) and the deployment-E2E suite maintainers.

Confidence: medium
Needs human?: yes — owner picker only; the fix itself is clearly described.

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.