RequestConflict when running ARM deployment of OpenAI

Question

During the deployment of Microsoft's Cognitive Services, an error was encountered.

The system returned a DeploymentFailed error, indicating that at least one resource deployment operation failed. Upon checking for further details, it was found that the error code RequestConflict was triggered. The deployment contains OpenAI instance and two model deployments.

Here is a bicep snippet that show how the resources are deployed:

resource ca 'Microsoft.CognitiveServices/accounts@2022-12-01' = {
  name: 'cog-openai-${appName}'
  location: location
  kind: 'OpenAI'
  sku: {
    name: 'S0'
  }
  properties:{
    publicNetworkAccess: 'Enabled'
    restrictOutboundNetworkAccess: false
    disableLocalAuth: false
    dynamicThrottlingEnabled: false
  }
}

resource ada 'Microsoft.CognitiveServices/accounts/deployments@2022-12-01' = {
  name: 'embedding-ada'
  parent: ca
  properties: {
    scaleSettings: {
      scaleType: 'Standard'
    }
    model: {
      format: 'OpenAI'
      name: 'text-embedding-ada-002'
      version: '2'
    }
  }
}

resource gpt 'Microsoft.CognitiveServices/accounts/deployments@2022-12-01' = {
  name: 'gpt-35-turbo'
  parent: ca
  properties: {
    scaleSettings: {
      scaleType: 'Standard'
    }
    model: {
      format: 'OpenAI'
      name: 'gpt-35-turbo'
      version: '0301'
    }
  }
}

The root cause of this conflict appears to be due to another operation being concurrently performed on the parent resource. The thing is that the cognititve account already exists and the deployments are also existing - there should be no update as I'm just re-deploying the same thing without changes. This makes the pipeline to fail and prevents other resources from being deployed.

Answer 1

We experienced the same issue around 10/9/23, 2:30pm EST as well. As per Microsoft, we were hitting the limit the role assignment limit under hobo subscription (which is used by Microsoft when they create new customer account). Microsoft rolled out the fix this afternoon in East US2 and North Central US region. After this fix, we are not getting this error anymore.