Detect active deployments before provisioning

[spboyer]

Summary

Fixes #7248

Before starting a deployment, azd now checks for active deployments on the target scope. If another deployment is in progress, it warns the user and waits for it to complete — avoiding the DeploymentActive ARM error that wastes ~5 minutes of the user's time.

Telemetry Context

• 199 DeploymentActive failures in March (~270/month projected)
• Average wait before failure: 5.3 minutes (P90: 12.2 min)
• 78% from provision, 19% from up

Changes

Pre-deployment active check (bicep_provider.go)

Added waitForActiveDeployments() between preflight validation and deployment submission:

• Lists deployments filtered for active provisioning states
• If found: warns with deployment names, polls at 30s intervals
• Timeout: 30 minutes (matches typical long deployments)
• Only ignores ErrDeploymentsNotFound (scope doesn't exist yet); other errors propagate

Active state classification (deployments.go)

IsActiveDeploymentState() classifies 11 provisioning states as active, including transitional states (Canceling, Deleting, DeletingResources, UpdatingDenyAssignments) that can still block new deployments.

Scope interface (scope.go)

Added ListActiveDeployments() to both ResourceGroupScope and SubscriptionScope.

Error suggestion (error_suggestions.yaml)

Added DeploymentActive rule with user-friendly message and ARM troubleshooting link.

Test Coverage (8 tests, 24 subtests)

Test	Coverage
TestIsActiveDeploymentState	17 subtests covering all provisioning states
TestWaitForActiveDeployments_NoActive	Happy path
TestWaitForActiveDeployments_InitialListError_NotFound	RG doesn't exist yet
TestWaitForActiveDeployments_InitialListError_Other	Auth/throttle errors propagate
TestWaitForActiveDeployments_ActiveThenClear	Polling until clear
TestWaitForActiveDeployments_CancelledContext	Context cancellation
TestWaitForActiveDeployments_PollError	Error during polling
TestWaitForActiveDeployments_Timeout	30min timeout

Related

• Improve Container Apps provisioning error handling and classification #7249 — Container Apps error handling (separate PR Add Container Apps and ARM error suggestions #7250)
• Preflight check: detect Azure Policy blocking local authentication #7179 — Preflight Azure Policy check (vhvb1989)

[Copilot]

Pull request overview

Adds a pre-deployment check that detects in-progress ARM deployments at the target scope and waits for them to complete, avoiding DeploymentActive failures during provisioning.

Changes:

• Introduces waitForActiveDeployments() in the Bicep provisioning flow and polls until deployments clear or a timeout is reached.
• Adds IsActiveDeploymentState() plus new tests to classify which provisioning states are considered “active”.
• Extends infra.Scope with ListActiveDeployments() and adds a DeploymentActive error suggestion rule.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
cli/azd/resources/error_suggestions.yaml	Adds a user-facing suggestion for DeploymentActive ARM errors.
cli/azd/pkg/infra/scope.go	Extends scope interface + implements ListActiveDeployments() for RG and subscription scopes.
cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go	Adds wait loop before deployment submission, with polling/timeout defaults.
cli/azd/pkg/infra/provisioning/bicep/bicep_provider_test.go	Updates mocked scope to satisfy the new Scope interface.
cli/azd/pkg/infra/provisioning/bicep/active_deployment_check_test.go	Adds tests covering wait-loop behavior, errors, cancellation, and timeout.
cli/azd/pkg/azapi/deployments.go	Adds IsActiveDeploymentState() helper.
cli/azd/pkg/azapi/deployment_state_test.go	Adds unit tests for active/inactive state classification.

[spboyer]

Telemetry Context: DeploymentActive + Retry Behavior

This PR addresses DeploymentActive (199 errors/month). Additional context from the deep dive:

Retry behavior makes this especially valuable

Of machines that hit InvalidTemplateDeployment errors (which includes DeploymentActive in the chain):

• 66% retry without changing anything — for DeploymentActive, this means they re-submit and hit the same active deployment again
• Average 3.6 retries per machine before they either succeed or give up
• The detect-and-wait pattern in this PR would break that retry loop immediately

Time savings

• DeploymentActive users currently wait an average deployment duration before failing, then retry
• With this PR: one wait period (with progress feedback) instead of N failed attempts × deployment time each

This is a clean win — the fix is architecturally simple (poll + wait) and eliminates a category of failure that can never be solved by retrying.