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.

[kristenwomack]

@copilot - will you check to ensure we have metrics coverage so we can see how often this error and fix occur after merging this change?

[Copilot]

@kristenwomack I've opened a new pull request, #7288, to work on those changes. Once the pull request is ready, I'll request review from you.

[spboyer]

Converting to draft — the active deployment check integration point in Deploy() causes nil-pointer panics in existing test mocks. The test infrastructure creates Deployment objects with nil inner scopes, and scopeForTemplate requires provider state that isn't available in all test paths.

Need to either:

1. Restructure as a standalone pre-deployment middleware (avoids touching the Deploy code path)
2. Add the check at the provision action level (internal/cmd/provision.go) before it calls into the bicep provider

The standalone tests for waitForActiveDeployments, IsActiveDeploymentState, and the error suggestion rule all pass. Only the integration with the existing Deploy flow is problematic.

[spboyer]

/azp run

[azure-pipelines]

You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list.

[spboyer]

/azp run azure-dev - cli

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[spboyer]

/azp run azure-dev - cli

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[spboyer]

/azp run azure-dev - cli

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[spboyer]

/azp run azure-dev - cli

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[spboyer]

Code Review

1. ErrDeploymentsNotFound not handled in poll loop

cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:693-696 — Medium

The initial ListActiveDeployments call (line 631) correctly handles ErrDeploymentsNotFound by returning nil. The polling loop does not. If the resource group is deleted externally while azd is waiting for active deployments to drain, the next poll returns ErrDeploymentsNotFound and surfaces it as a hard error. The deployment should proceed — the resource group is gone, so there are no conflicts.

Fix: Add the same ErrDeploymentsNotFound guard inside the ticker.C case:

case <-ticker.C:
    active, err = infra.ListActiveDeployments(ctx, scope)
    if err != nil {
        if errors.Is(err, infra.ErrDeploymentsNotFound) {
            return nil
        }
        return fmt.Errorf("checking active deployments: %w", err)
    }

---

2. Active-deployment check only queries one deployment backend

cli/azd/pkg/infra/scope.go:29 — Medium

ListActiveDeployments delegates to scope.ListDeployments(), which comes from whichever single azapi.DeploymentService was selected in DI. In standard mode it only sees ARM deployments; in deployment-stacks mode it only sees stacks. An active deployment of the other kind at the same scope is invisible, so azd up can still hit DeploymentActive despite the guard passing.

Worth noting in the PR description as a known limitation, or adding a combined query for conflict detection.

---

3. Race window between wait completion and deploy request

cli/azd/pkg/infra/provisioning/bicep/bicep_provider.go:816 — Low

The wait loop exits when zero active deployments are found, then proceeds to deployModule. A concurrent deployment starting in that gap still produces DeploymentActive. This is inherent to the check-then-act pattern and cannot be fully eliminated without retry-on-conflict logic. Consider noting this as a known limitation, and optionally adding a retry path if the deploy call itself returns DeploymentActive.