Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Deployment submitted twice under the same name, second submission fails the step with DeploymentActive while the first succeeds

Open
  • Is something wrong?
#328 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
azure, github-actions, typescript
Domain
ci-cd, cloud, devops

Research direction

Begin at the deployment create operation in azure/bicep-deploy v2.3.0 and reproduce the duplicate ARM submission using the reported deterministic name and timing. Trace the request or retry path beneath the single start log, then verify that an in-flight DeploymentActive from the action's own request waits for the deployment and that a final Succeeded state leaves the workflow successful.

Written by the indexing model from the issue text.

Description

What happened

A single type: deployment, operation: create step submitted the same deployment name to ARM twice, about 30 seconds apart. The first submission was accepted and ran to completion successfully. The second one was rejected with DeploymentActive, and the action failed the step.

The net effect is a false negative: the infrastructure deployed exactly as intended, but the workflow reported failure, which cascaded into every downstream job being skipped.

Timeline from one run

All times UTC, single job, no retries by us and no concurrent workflow targeting the same resource group.

Time Event
19:58:51.706 Action logs Starting deployment create at resourceGroup '<rg>' scope with name '<deployment-name>'
19:59:07 ARM registers a deployment under that name, correlationId 22e39e73-1fae-41d1-b4cf-3f786036a3cd
19:59:21.035 Action reports Request failed. CorrelationId: f9fd7c69-f160-4418-ac18-50d2c9224f06 with DeploymentActive, then Create failed
20:00:08.655 The deployment registered at 19:59:07 completes, provisioningState: Succeeded, duration: PT1M1.34S

Two different correlation IDs for what was configured as one deployment is the tell: the client issued the request twice.

Error body, subscription id redacted:

{
  "code": "DeploymentActive",
  "message": "The deployment with resource id '/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Resources/deployments/<deployment-name>' 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/8/2026 7:59:07 PM' with correlationId '22e39e73-1fae-41d1-b4cf-3f786036a3cd', and will expire at '9/15/2026 7:59:07 PM' if it does not complete before then."
}
Expected behaviour

Either the submission is not retried, or a retry that hits DeploymentActive for the deployment name the action itself just submitted is recognised as its own in-flight request and the action waits on it instead of failing. A deployment that reaches Succeeded should not surface as a failed step.

Why it matters

DeploymentActive arrives roughly 30 seconds in, while the real deployment still has most of its runtime left, so the job fails early and the caller has no signal that the work is still progressing and will succeed. In our case the failed leg of a deploy matrix skipped five downstream application-code deployment jobs, leaving the environment on new infrastructure with old application code until the run was manually re-run. The re-run then succeeded with no changes.

It is also awkward to guard against from the outside: a workflow can only work around it by letting the step fail soft and then polling provisioningState for the deployment name to decide whether the failure was real.

Environment
  • Action: azure/bicep-deploy v2.3.0 (66910e9c5c7733c33a1cd605030d02234b3bc4ed)
  • Inputs: type: deployment, operation: create, scope: resourceGroup, parameters file .bicepparam, bicep-version: 0.46.1
  • Runner: self-hosted Linux
  • Deployment name is deterministic and unique per run (it embeds the run id), so the collision is with the action's own earlier submission, not with a different workflow.
Notes

I have not been able to determine from the logs whether the first HTTP request failed client side (timeout or 5xx) and was retried, or whether the request is issued twice by design. The action's own log line for starting the deployment appears once, which suggests the duplication happens below that layer. Happy to supply more log detail if useful.

Dominant language
TypeScript
Stars
66
Forks
20
Avg merge
16h 13m
Merged PRs (30d)
22

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Azure/bicep-deploy

All issues in Azure/bicep-deploy

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.