Repository navigation
Never abort deployment on validation errors - always let user choose #7115
Description
Context
Follow-up from PR #7053 review. Parent tracking issue: #7112
PR Conversations
- Should never abort deployment (tg-msft, Victor Vazquez (@vhvb1989))
- Remove abort code for errors (tg-msft)
What needs to change
- Remove code that blocks/aborts deployment when validation errors are found.
- Always ask the user whether to stop and fix or try to deploy anyway, even for errors that seem certain to fail.
- Validation should be strictly informational with ignorable warnings — forward compatibility concerns mean we should never block based on heuristics that could become stale.
Files to update
cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go(line ~2185)cli/azd/docs/design/local-preflight-validation.md(update design to reflect non-blocking behavior)
Metadata
Metadata
Assignees
Labels
No labels
Activity
spboyer commentedon Mar 23, 2026
Telemetry data supporting the "never abort" direction.
From Kusto analysis of
service.arm.deployment.failedin March 2026 (23 days):RoleAssignmentExistsaccounts for 351 ARM deployment failures per month (4.0% of inner error codes). These are not real failures -- the role assignment already succeeded on a previous run. The current behavior treats an idempotent success state as a deployment-blocking error.Additionally,
DeploymentActive(199/mo) represents cases where a previous deployment is still running. Rather than aborting, azd could detect this and wait for the in-progress deployment to complete.Both of these support treating certain "errors" as warnings rather than abort conditions:
Data source:
ddazureclients.kusto.windows.net/DevCli/RawEventsAppRequests, March 1-23, 2026.vhvb1989 commentedon Apr 6, 2026
Feature is already working like this.
Warnings prompt users if they want to continue or not