Incorrect property array index when referencing an app service's slot

[jhoops88]

Bicep version
Bicep CLI version 0.4.63 (7ebed03)

Describe the bug
Transpilation of Bicep to ARM for an app service's slot's principal ID creates an invalid array reference (The language expression property array index '1' is out of bounds)

To Reproduce
This is occurring when attempting to setup an access policy for an existing app service's slot to a key vault (the key vault is created in the Bicep resource).

Bicep template: (shortened for brevity)

param appServiceName string

resource stagingAppService 'Microsoft.Web/Sites/Slots@2020-12-01' existing = {
  name: appServiceName
}

resource symbolicname 'Microsoft.KeyVault/vaults@2019-09-01' = {
  name: 'key-vaults-name'
  location: location
  properties: {
    accessPolicies: [
      {
        tenantId: subscription().tenantId
        objectId: redacted
        permissions: {
          keys: [
            'get'
          ]
          secrets: [
            'get'
          ]
          certificates: [
            'get'
          ]
        }
      }
      {
        tenantId: subscription().tenantId
        objectId: stagingAppService.identity.principalId
        permissions: {
          secrets: [
            'get'
            'list'
          ]
        }
      }
    ]
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: subscription().tenantId
    enabledForDeployment: false
    enabledForDiskEncryption: false
    enabledForTemplateDeployment: false
    enableSoftDelete: true
  }
}

ARM resource transpilation: (only showing erroneous resource)

{
      "type": "Microsoft.KeyVault/vaults",
      "apiVersion": "2019-09-01",
      "name": "key-vaults-name",
      "location": "[parameters('location')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[subscription().tenantId]",
            "objectId": "redacted",
            "permissions": {
              "keys": [
                "get"
              ],
              "secrets": [
                "get"
              ],
              "certificates": [
                "get"
              ]
            }
          },
          {
            "tenantId": "[subscription().tenantId]",
            "objectId": "[reference(resourceId('Microsoft.Web/sites/slots', split(parameters('appServiceName'), '/')[0], split(parameters('appServiceName'), '/')[1]), '2020-12-01', 'full').identity.principalId]",
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]
            }
          }
        ],
        "sku": {
          "family": "A",
          "name": "standard"
        },
        "tenantId": "[subscription().tenantId]",
        "enabledForDeployment": false,
        "enabledForDiskEncryption": false,
        "enabledForTemplateDeployment": false,
        "enableSoftDelete": true
      }
    }

The error occurs on this line:
"objectId": "[reference(resourceId('Microsoft.Web/sites/slots', split(parameters('appServiceName'), '/')[0], split(parameters('appServiceName'), '/')[1]), '2020-12-01', 'full').identity.principalId]"
The template resource 'key-vaults-name' at line '37' and column '9' is not valid: The language expression property array index '1' is out of bounds..
Which is the tranpilation of the Bicep line:
objectId: stagingAppService.identity.principalId

Additional context
This happens when attempting to deploy resources using the Bicep build's ARM template. The same error occurs on our pipeline when using the "New-AzResourceGroupDeployment" command with the Bicep resource template.

[anthony-c-martin]

It sounds like the issue is with the parameter value being passed to appServiceName - because it's defined as the name for a child resource type, ARM expects there to be 2 segments to it.

I'd expect instead of the following:

param appServiceName string

resource stagingAppService 'Microsoft.Web/Sites/Slots@2020-12-01' existing = {
  name: appServiceName
}

You would instead need something like:

param appServiceName string
param slotName string

resource stagingAppService 'Microsoft.Web/Sites/Slots@2020-12-01' existing = {
  name: '${appServiceName}/${slotName}'
}

Alternatively, if you're just looking to hardcode the slot name (e.g. 'staging'), you can also do:

param appServiceName string

resource stagingSlot 'Microsoft.Web/Sites/Slots@2020-12-01' existing = {
  name: '${appServiceName}/staging'
}

[macux]

This makes sense however it's not at all obvious from the bicep code that it would cause the issue it did - will this kind of thing get caught by the tooling in due course? E.g. in a similar way to how ARM template validation complains if you don't have enough segments in names.

Edit - your original post @anthony-c-martin showed a parent property which feels nicer and easier to validate, is this actually a thing?

[anthony-c-martin]

Edit - your original post @anthony-c-martin showed a parent property which feels nicer and easier to validate, is this actually a thing?

Yes - I was trying not to overcomplicate my solution 😄 the following is also valid:

param appServiceName string
param slotName string

resource appService 'Microsoft.Web/Sites@2020-12-01' existing = {
  name: appServiceName
}

resource stagingSlot 'Microsoft.Web/Sites/Slots@2020-12-01' existing = {
  parent: appService 
  name: slotName
}

Documentation on parent here: https://github.com/Azure/bicep/blob/main/docs/spec/resource-scopes.md#parent-child-syntax

There's also proposal to provider a much shorter syntax under #2245 to obtain a reference to an existing resource. Manually formatting names with / is always error-prone, and not always possible to catch before deployment - my eventual plan is to completely prevent the ability to do this in Bicep by providing more attractive and safe options (such as the parent property, and the methods discussed in #2245).

[alex-frankel]

Looks like the core issue has been resolved. Going to close this with the expectation that these newer, safer methods that @anthony-c-martin has detailed will prevent most people from running into this issue in the first place.