multiple resource loops creates an out of bounds error

[bmoore-msft]

Bicep version
Bicep CLI version 0.4.1272 (a69022d)

Describe the bug
I think what's happening is that when we create an n*m parent/child set of resources, the copyIndex() from the n named resource is used in the m loop and can create an index out of bounds problem. I was not able to figure out how to fix this logic in bicep, but could manually author the template in json.

To Reproduce
Compile this file and load the json in VS code, it will flag the error.

var numberOfAccounts = 2
var blobsPerAccount = 3
var saprefix = uniqueString(resourceGroup().id)

resource sa 'Microsoft.Storage/storageAccounts@2021-08-01' = [for i in range(0, numberOfAccounts): {
  name: '${saprefix}${i}'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}]

resource blobSvc 'Microsoft.Storage/storageAccounts/blobServices@2021-08-01' = [for i in range(0, numberOfAccounts): {
  parent: sa[i]
  name: 'default'
}]

resource containers 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-08-01' = [for i in range(0, (numberOfAccounts * blobsPerAccount)): {
  parent: blobSvc[i % numberOfAccounts]
  name: 'container${i % blobsPerAccount}'
}]

Additional context
This is a working json template for the scenario (manually authored)

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "variables": {
    "numberOfAccounts": 2,
    "blobsPerAccount": 3,
    "saprefix": "[uniqueString(resourceGroup().id)]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2021-08-01",
      "name": "[format('{0}{1}', variables('saprefix'), copyIndex())]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "copy": {
        "name": "sa",
        "count": "[variables('numberOfAccounts')]"
      }
    },

    {
      "type": "Microsoft.Storage/storageAccounts/blobServices",
      "apiVersion": "2021-08-01",
      "name": "[format('{0}{1}/default', variables('saprefix'), copyIndex())]",
      "copy": {
        "name": "blobServices",
        "count": "[variables('numberOfAccounts')]"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', format('{0}{1}', variables('saprefix'), copyIndex()))]"
      ]
    },
    {
      "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
      "apiVersion": "2021-08-01",
      "name": "[format('{0}{1}/{2}/{3}{4}', variables('saprefix'), mod(copyIndex(), variables('numberOfAccounts')), 'default', 'container', mod(copyIndex(), variables('blobsPerAccount')))]",
      "copy": {
        "name": "blobs",
        "count": "[mul(variables('numberOfAccounts'), variables('blobsPerAccount'))]"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', format('{0}{1}', variables('saprefix'), mod(copyIndex(), variables('numberOfAccounts'))))]",
        "[resourceId('Microsoft.Storage/storageAccounts/blobServices', format('{0}{1}', variables('saprefix'), mod(copyIndex(), variables('numberOfAccounts'))), 'default')]"
      ]
    }
  ]
}

[majastrz]

The generated template also fails preflight and will not deploy.

[alex-frankel]

FYI - if you don't use the parent property, and instead use "fully-qualified" resource names, you can workaround this issue, i.e.

resource grandChild 'Microsoft.Storage/storageAccounts/blobServices/containers' = {
  name: 'grandParentName/parentName/childName'
}

I imagine that is not fun to author with the complexity required here, but if this is blocking anyone, I wanted to make folks aware. @majastrz is actively working on a fix.

[slavizh]

@bmoore-msft @alex-frankel already logged long time ago #5269

[alex-frankel]

@majastrz -- can you take a look at the linked issue and close if it is a dup? I noticed that in that issue the example only uses the parent keyword for the child resource not the grandchild.

[alex-frankel]

#4453 also seems like a potential dup

[majastrz]

#4453 is a different issue. #5269 is also a different issue.

[slavizh]

I still hope all will be fixed :)