[BUG]: BicepDeploy@0 reports DeploymentNotFound for a deployment it just created

[auslavs]

New issue checklist

• I searched for existing GitHub issues
• I read pipeline troubleshooting guide
• I checked how to collect logs

Task name

BicepDeploy

Task version

0.279.0 (also reproduced on 0.278.0)

Issue Description

The task submits a deployment create, then reports DeploymentNotFound for that same deployment name a few seconds later and fails with Create failed. The deployment was in fact created and goes on to complete successfully — this looks like a read-after-write race between the create call and the first status poll.

The failure is then made unrecoverable by retryCountOnTaskFailure: the retry re-submits the same deployment name while the original (healthy) deployment is still running, so ARM rejects it with DeploymentActive. Every subsequent retry does the same. The task ends failed while the deployment it started succeeds.

Proof the deployment existed and succeeded. In the log below, the task reports DeploymentNotFound at 17:53:12. The DeploymentActive error on the first retry names the deployment it collided with as "started at '9/9/2026 5:53:12 PM' with correlationId 044388c3-5190-4a92-93aa-ce4427cb043d" — the same second the task said it could not be found. Querying ARM afterwards:

$ az deployment sub show --name infra-deploy-1001
{
  "name":  "infra-deploy-1001",
  "state": "Succeeded",
  "dur":   "PT35.7968338S",
  "corr":  "044388c3-5190-4a92-93aa-ce4427cb043d"
}

Same correlation ID, provisioning state Succeeded, finished at 17:53:48 — 15 seconds after the task had already failed the step.

Timing is the discriminator, not configuration. A successful run of the identical pipeline with identical task inputs polls without complaint for 50 seconds:

17:55:05  Starting deployment create at subscription '<subscription-id>' scope with name 'infra-deploy-1002'
17:55:55  ##[section]Finishing: Bicep Deployment      <- 50s, no error

The failing run errors 5 seconds after create. Service principal, subscription selection, scope and parameters are identical between the two.

Frequency. Across 439 BicepDeploy task executions in 23 pipelines (last ~25 runs of each), all Microsoft-hosted ubuntu-latest:

Outcome	Count	Rate
Hit the DeploymentNotFound race	23	5.2%
→ rescued by a retry (step went green)	14
→ hard task failure	9	2.1%
Unrelated genuine failures	2	0.5%

Whether a retry rescues the run depends on how long the deployment takes. Retries fire at +1s and +4s, so any deployment longer than ~5 seconds is guaranteed to hit DeploymentActive on every retry. Our ~35s deployment fails 100% of the time once the race fires; faster ones usually recover.

Two further observations that may help:

1. When a retry does rescue the run, only the final attempt's log is retained. The DeploymentNotFound / DeploymentActive text survives only in the timeline record's issues array, not in any downloadable log. This makes the problem very hard to spot — the step is green and the log is clean.
2. Re-submitting the same deployment name on retry seems wrong regardless of this bug. A retry can only ever succeed if the original deployment has already finished.

Identifiers in the log below are replaced with placeholders; the unredacted log and the subscription ID can be supplied on request.

Environment type (Please select at least one enviroment where you face this issue)

• Self-Hosted
• Microsoft Hosted
• VMSS Pool
• Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Agent version

Microsoft-hosted ubuntu-latest

Operation system

Linux (Microsoft-hosted ubuntu-latest)

Relevant log output

# Subscription/tenant GUIDs, deployment names, step names and the parameters filename
# are replaced with placeholders. Timestamps, error payloads and correlation IDs are verbatim.

##[section]Starting: Bicep Deployment
==============================================================================
Task         : Bicep Deploy
Version      : 0.279.0
==============================================================================
[Host] Selected Node version: Node24 (Strategy: Node24Strategy)
Setting AZURE_CONFIG_DIR env variable to: /home/vsts/work/_temp/.bicepdeploy-Z9pqnt
[command]/usr/bin/az login --service-principal -u *** --tenant *** --allow-no-subscriptions --federated-token ***
[command]/usr/bin/az account set --subscription <subscription-id>

17:53:07  Starting deployment create at subscription '<subscription-id>' scope with name 'infra-deploy-1001'
17:53:07  Using parameters file: /home/vsts/work/1/s/self/deployment/bicep/main.bicepparam
17:53:07  Downloading Bicep version 0.47.16...
17:53:08  Caching tool: bicep 0.47.16 x64

17:53:12  ##[error]Request failed. CorrelationId: fd7f3d68-6d6f-4898-b336-48904b4cffac
17:53:12  ##[error]{
            "code": "DeploymentNotFound",
            "message": "Deployment 'infra-deploy-1001' could not be found."
          }
17:53:12  ##[error]Create failed
17:53:13  ##[warning]RetryHelper encountered task failure, will retry (attempt #: 1 out of 2) after 1000 ms

17:53:17  Starting deployment create at subscription '<subscription-id>' scope with name 'infra-deploy-1001'
17:53:20  ##[error]Request failed. CorrelationId: 289ce7ab-7221-4ba3-87a0-93efc50e33a9
17:53:20  ##[error]{
            "code": "DeploymentActive",
            "message": "The deployment with resource id '/subscriptions/<subscription-id>/providers/Microsoft.Resources/deployments/infra-deploy-1001' cannot be saved, because this would overwrite an existing deployment which is still active. If this is an intentional re-deployment, please wait for the original deployment to complete, or cancel it before re-attempting the operation. The previous deployment was started at '9/9/2026 5:53:12 PM' with correlationId '044388c3-5190-4a92-93aa-ce4427cb043d', and will expire at '9/16/2026 5:53:12 PM' if it does not complete before then."
          }
17:53:20  ##[error]Create failed
17:53:21  ##[warning]RetryHelper encountered task failure, will retry (attempt #: 2 out of 2) after 4000 ms

17:53:30  Starting deployment create at subscription '<subscription-id>' scope with name 'infra-deploy-1001'
17:53:33  ##[error]Request failed. CorrelationId: a5614732-de9f-45ff-916a-c26985c286d3
17:53:33  ##[error]{
            "code": "DeploymentActive",
            "message": "... as above; previous deployment started at '9/9/2026 5:53:12 PM' with correlationId '044388c3-5190-4a92-93aa-ce4427cb043d' ..."
          }
17:53:33  ##[error]Create failed
17:53:34  ##[section]Finishing: Bicep Deployment

# ARM, queried afterwards: infra-deploy-1001 -> Succeeded, PT35.7968338S,
# correlationId 044388c3-5190-4a92-93aa-ce4427cb043d, completed 17:53:48

Full task logs with system.debug enabled

No response

Repro steps

1. BicepDeploy@0 step, scope: subscription, ARM service connection using workload identity federation, Microsoft-hosted ubuntu-latest.
2. Give it a template that takes ~30s or more to deploy.
3. Set retryCountOnTaskFailure: 2 on the step.
4. Run it repeatedly. Roughly 1 execution in 20 reports DeploymentNotFound for the deployment name it just created; with a deployment of that length every retry then fails with DeploymentActive and the step fails, even though the deployment succeeds.

Expected: the task polls the deployment it created and reports its real outcome.

Actual: the task reports DeploymentNotFound moments after a successful create, and the retry path collides with the still-running original.