Azure Key Vault soft-delete conflict can require AppHost model change when tombstone is not discoverable

[davidfowl]

Summary

A manually deleted implicit Azure Key Vault can leave an Aspire app in a state where resource commands cannot fully recover without changing the AppHost model.

Observed flow

1. A PostgreSQL resource uses password authentication, which creates an implicit child Key Vault resource.
2. The Key Vault is manually deleted outside Aspire while provisioning state is incomplete or failed.
3. reprovision tries to recreate the same generated vault name.
4. ARM returns a Key Vault ConflictError saying the vault name already exists in deleted state and must be recovered or purged.
5. Azure deleted-vault APIs and CLI do not find the deleted vault, so purge/recover cannot be performed.
6. The Aspire delete-azure-resource path cannot act on the child Key Vault because cached deployment state does not contain a usable resource ID.

Result

The only practical escape was to change the AppHost model so the resource generated a new Key Vault name, then restart the AppHost. That means the no-restart recovery story is incomplete for this edge case.

Expected behavior

Aspire should either provide a no-restart recovery path for this state or surface a clearer diagnostic explaining that the Azure provider reports a deleted-state name conflict but the deleted vault is not discoverable for purge/recover.

Notes

This issue intentionally omits subscription IDs, tenant IDs, local paths, generated vault names, and other environment-specific details.

[davidfowl]

Follow-up from a second isolated repro:

Additional finding

There are two related states here:

Recoverable state

If Aspire still has cached deployment state with a Key Vault resource ID, the app can recover without restarting the AppHost.

Working no-restart sequence:

aspire resource <parent> cancel-azure-operation
aspire resource <child-kv> delete-azure-resource
aspire resource <child-kv> reprovision
aspire resource <parent> reprovision

Important detail: the child Key Vault delete/purge can take several minutes. After it completes, the child Key Vault should be reprovisioned before reprovisioning the parent PostgreSQL resource. Reprovisioning the parent first can still fail because its implicit Key Vault dependency is not ready.

Still-broken state

The original gap remains when all of these are true:

1. ARM reports a Key Vault deleted-state conflict for the generated vault name.
2. Azure deleted-vault APIs cannot find the tombstone to purge or recover.
3. Aspire no longer has a cached resource ID for the child Key Vault.

In that state, delete-azure-resource cannot act on the child Key Vault, and reprovision keeps trying the same generated name. The only escape observed was changing the AppHost model so a new generated vault name is used, which requires restarting the AppHost.

Potential fixes

1. Make parent reprovision repair owned implicit children first. For example, reprovision on a PostgreSQL resource using password authentication should detect that its owned Key Vault is NotStarted, Canceled, or Failed, then provision the Key Vault before provisioning PostgreSQL.

2. Preserve and reuse Key Vault failure targets. If ARM returns a failed target resource ID in diagnostics, keep enough metadata for the child resource command path to attempt purge/recover later, even when normal cached deployment state is missing.

3. Improve diagnostics for the Azure inconsistency case. If ARM reports a deleted-state conflict but deleted-vault lookup returns not found, surface that as a known Azure propagation/inconsistency state and suggest retrying child delete/reprovision or changing Azure context/resource group/name as the final escape hatch.

[joperezr]

🤖 Aspire triage pass — 2026-06-22 16:58 UTC

Area: area-app-model (already applied; touches Azure provisioning resource commands, so area-deployment may also be appropriate — leaving to human)
Kind: bug
Repro: yes-large — flow described in body lines 5–13, with refined no-restart sequence and still-broken state in the follow-up comment
Affected version(s): not specified by reporter; latest shipped is 13.4.0
Severity: S3 — edge case (manual Azure-side deletion of an implicit child Key Vault during incomplete/failed provisioning) with a documented workaround (change the AppHost model so a new generated vault name is used, then restart the AppHost)

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: No evidence this is a 13.4 regression — reporter does not cite a prior working version, and the gap is described as an incomplete recovery story for an edge case rather than newly broken behavior. A workaround exists. Clean, high-quality bug report from a member in a core area, so worth pulling into 13.5 rather than backlog.

Suggested owner(s): @JamesNK (score ≈46), backup @karolz-ms (score ≈13)
Evidence:

• JamesNK authored 13+ merged PRs in area-app-model in the last 90 days (e.g. Fix resource service port collision in --isolated mode #18332, Fix flaky profiling tests by scoping ActivityListeners to specific instances #18304, Make ResourceAnnotationCollection thread-safe #18259, Support wildcard ignore patterns for pre-release version checks #18233, Fix DistributedApplicationTestingBuilder dashboard with dynamic ports #17729, Use KnownConfigNames for resource service endpoint URL with legacy fallback #17385, Use OrdinalIgnoreCase for EnvironmentVariableName comparer #17194, CLI: Print app host CLI log path when connected to a running app host #17168, Improve version log messages in CLI, AppHost and dashboard #17163, Use ASPIRE_APPHOST_LOGLEVEL instead of cascading Logging__LogLevel__Default #17071, Use arguments for built-in resource commands #17021, Handle non-interactive interaction service availability for resource commands #16973, Fix OTLP endpoint resolution in isolated mode #16367)
• JamesNK closed-as-completed in area-app-model: [13.3] Interaction Service is unaware if command is invoked from CLI #16720, Add TryGetByName #16388, When started under isolated mode, no Traces and metrics are displayed in the Aspire dashboard #16037
• karolz-ms closed-as-completed in area-app-model: [AspireE2E]After stopping the first resource, the second resource can't be stop and the dashboard will shut down #17201, [13.3.2] Resource fails to start due to concurrency error in CreateContainerNetworkServicesForHostResource #17083, project resources stayed infinite waiting state #16976, Container console logs showing out of order #16639, Container resource named aspire will lead to container network conflict #16644, "aspire stop" is not gracefully shutting down the docker containers it starts. #15806
• CODEOWNERS for /src/Aspire.Hosting lists @JamesNK and @karolz-ms
• Note: the underlying provisioning code likely also touches /src/Aspire.Hosting.Azure (CODEOWNERS: @eerhardt @mitchdenny) — human may want to loop them in if root cause is in the Azure provider

Confidence: medium
Needs human?: yes — affected-version field is empty (worth confirming this reproduces on 13.4.0 specifically, in case it is actually a regression that would change the milestone recommendation); also worth a quick human check on whether the right area is area-app-model vs. adding area-deployment

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