Why does my C# code keep failing with “Resource cannot be updated during provisioning” even after multiple retries and delays?

Question

"error": { "code": "BadRequest", "message": "Resource cannot be updated during provisioning", "target": "orbitaxbdltdstorageventtrigger", "details": null }

Answer 1

The error means the target Azure Data Factory resource is still in an active provisioning operation at the platform level, so any update call from C# is rejected until that operation reaches a terminal state. Client-side retries and delays do not help if the backend operation is stuck.

From similar Azure resource behaviors, this typically occurs when:

1. A previous ARM/SDK operation is still running or hung
   • For example, a prior create/update/delete on the trigger or its parent resource hasn’t completed.
   • While the provisioning state is non-terminal (such as Updating or Deleting), the control plane blocks further modifications and returns BadRequest-style errors.
2. A delete/recreate sequence resurrects a half-deleted resource
   • Deleting a parent resource (for example, an Event Grid or system topic–like dependency) and then recreating it with the same name can “revive” the old, stuck instance instead of creating a clean one.
   • In that situation, child resources (like triggers/subscriptions) can appear in Deleting or Updating and cannot be changed, which leads to repeated Resource cannot be updated during provisioning responses.
3. The resource is stuck in provisioning and only the platform can fix it
   • Once a resource is stuck in a non-terminal provisioning state, all client calls (including C# retries with backoff) will continue to fail until the backend operation is completed, rolled back, or force-cleaned by the service team.

Because of this, the C# code keeps failing even after multiple retries and delays: the problem is not transient latency but a blocked or stuck provisioning state on the Azure side.

A practical remediation pattern, based on similar cases, is:

1. Stop automatic retries in the C# code
   • Continuing to hammer the same resource while it is stuck will not change its state and only produces more BadRequest errors.
2. Inspect the resource state directly
   • Use the Azure portal or ARM/CLI to check the provisioning state of the Data Factory trigger and any related resources (for example, Event Grid/system topics or storage-linked triggers).
   • If the state remains Updating or Deleting for a long period and operations fail with conflicts or BadRequest, treat it as stuck.
3. If the resource is stuck, escalate to Azure support
   • When a resource is stuck in provisioning and cannot be updated or deleted, the only effective resolution is for the Azure product team to clear or remove the stuck instance in the backend.
   • After support confirms the cleanup (or the resource finally disappears), recreate the trigger/resource cleanly and then re-enable the C# logic.
4. After cleanup, recreate rather than reuse the broken instance
   • If possible, create a new trigger/resource (or even a new parent resource) with a fresh name to avoid any hidden references to the old stuck object.

This behavior aligns with other Azure cases where resources (for example, Event Grid topic subscriptions) were stuck in Updating/Deleting and could not be updated or deleted until the service team intervened, after which normal create/update operations started working again.

---

References:

• event grid topic subscriptions stuck in Deleting state - Microsoft Q&A
• Azure Event Hubs - Resource Manager exceptions