Azure Communication Services resource-provider PUT permanently stuck in Accepted state; all subsequent PUTs return InvalidResourceOperation

Ken-199 0 Reputation points
2026-07-25T04:36:52.3033333+00:00

An Azure Communication Services resource is permanently rejecting management-plane PUT requests with HTTP 409 InvalidResourceOperation.

The original PUT began at 2026-07-21T20:22:04.6163518Z.

Correlation ID:

6aa28663-0423-453e-8d20-efa9d6a92560

Initial operation ID:

0de05f68-8396-4d91-b1c7-754a229f2b0d

The Azure Activity Log recorded the operation as Started, then Created, followed by repeated Accepted events approximately every two minutes through

2026-07-21T21:22:18Z. There is no terminal Succeeded or Failed event.

Every subsequent PUT immediately fails with:

InvalidResourceOperation: Another 'PUT' operation on the same resource is active/in-progress. Multiple concurrent operations of the same type (ex:

PUT) are disallowed for resource type communicationServices.

The issue has persisted for several days. The resource currently reports provisioningState: Succeeded and its data-plane functionality continues to

work. GET requests work, and PATCH requests have succeeded; only PUT requests are blocked.

This prevents the resource from being managed through ARM/Bicep deployments. We have temporarily excluded the Communication Services resource from

deployments as a workaround.

There is no active ARM deployment available for us to cancel, and the documented Communication Services resource-management API does not expose a

way to cancel the orphaned asynchronous operation.

Could a Microsoft engineer please escalate this to the Azure Communication Services resource-provider team and clear or complete the stale server-

side PUT operation associated with the correlation ID above?

I can provide the subscription ID, resource group, full resource ID, tenant ID, and additional Activity Log evidence privately to a Microsoft

representative. I have intentionally omitted those identifiers from this public post.

Azure Communication Services

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sina Salam 31,056 Reputation points Volunteer Moderator
    2026-07-26T18:38:53.5+00:00

    Hello Ken-199,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that your Azure Communication Services resource-provider PUT permanently stuck in Accepted state, and all subsequent PUTs return InvalidResourceOperation.

    This is a stale or orphaned Azure Communication Services resource-provider long-running PUT operation. ACS create/update is a PUT operation on Microsoft.Communication/communicationServices, and successful creation may return Azure-AsyncOperation with Retry-After, meaning the operation is tracked asynchronously by Azure Resource Manager. - https://learn.microsoft.com/en-us/rest/api/communication/resourcemanager/communication-services/create-or-update?view=rest-communication-resourcemanager-2026-03-18, https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/async-operations

    What you can do to resolve is not to keep retrying Bicep/ARM deployments. Since the original PUT has remained active for days, Microsoft Internal support must clear, complete, fail, or cancel the stale backend operation lock from the Azure Communication Services resource-provider side. Azure Resource Manager’s standard mitigation for AnotherOperationInProgress is to wait for the concurrent operation to complete, but that does not solve a stale operation that never reaches a terminal state. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/troubleshooting/common-deployment-errors, and https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/async-operations gives more insight.

    Therefore:

    • Stop redeploying the ACS resource with ARM/Bicep until the stale operation is cleared.
    • Keep the ACS resource excluded from normal deployments temporarily, or reference it as an existing resource.
    • Collect the Activity Log evidence using the correlation ID and operation ID.
    • Open an Azure technical support via your portal or contact Priority Customer Service, request escalation to the Azure Communication Services resource-provider engineering team. Ask to clear or complete the stale PUT operation lock.
    • Validate the fix only by running a fresh ARM/Bicep deployment that performs a new PUT successfully.

    After Microsoft clears the stale ACS resource-provider operation, the next ARM/Bicep deployment containing the ACS resource should complete successfully. The issue is not fully resolved until a new PUT completes and the resource remains in Succeeded state.

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.