Inccorrect existing resource reference when using user defined types feature

[slavizh]

Bicep version
v0.13.1

Describe the bug
When using the following experimental feature:

"experimentalFeaturesEnabled": {
        "userDefinedTypes": true
    }

When referencing resource in another resource group incorrect resource is being referenced. For example, if I have defined existing resource like this:

resource monitorWorkspace 'Microsoft.Monitor/accounts@2021-06-03-preview' existing = {
  name: azureMonitorWorkspace.name
  scope: resourceGroup(azureMonitorWorkspace.subscriptionId, azureMonitorWorkspace.resourceGroup)
}

and using later monitorWorkspace.id on another property it tries to look for the resource in the resource group where deployment is happening rather in the resource group that is defined in azureMonitorWorkspace.resourceGroup
When looking at the generated ARM template the code is the following:

...
"resources": {
        "monitorWorkspace": {
            "type": "Microsoft.Monitor/accounts",
            "apiVersion": "2021-06-03-preview",
            "name": "[parameters('azureMonitorWorkspace').name]",
            "existing": true,
            "subscriptionId": "[parameters('azureMonitorWorkspace').subscriptionId]",
            "resourceGroup": "[parameters('azureMonitorWorkspace').resourceGroup]"
        },
        "ruleGroupRes": {
            ...
            "properties": {
               ....
                "scopes": [
                    "[resourceInfo('monitorWorkspace').id]"
                ]
                ...
            }
        }
    }

When you do deployment you can clearly see that what-if reports that scope value will be changed and the only difference is that the resource group name where the resource is located is the one where the deployment is happening not the one defined via input parameters. Same code works fine when experimental feature is not enabled.

To Reproduce
Steps to reproduce the behavior:

Additional context
Add any other context about the problem here.

[slavizh]

@jeskew This seems fixed in latest bicep version. Not sure which change fixed it but I have tested it. ARM code that is generated now is:

"scopes": [
                          "[extensionResourceId(format('/subscriptions/{0}/resourceGroups/{1}', parameters('azureMonitorWorkspace').subscriptionId, parameters('azureMonitorWorkspace').resourceGroup), 'Microsoft.Monitor/accounts', parameters('azureMonitorWorkspace').name)]"
                        ],

[jeskew]

The resourceInfo function isn't used in code generation since #9458, but we still need to address the issue you ran into in the ARM runtime.

[Kittoes0124]

A similar regression happens with the following pattern. Works just fine when UDTs are disabled, but blows up with "The language expression property 'networkSecurityGroup' doesn't exist" or "The language expression property 'publicIpAddresses' doesn't exist" when enabled.

param location string = resourceGroup().location
param name string
param properties object
param tags object = {}

var isNetworkSecurityGroupNotEmpty = !empty(properties.?networkInterface ?? {})
var resourceGroupName = resourceGroup().name
var subscriptionId = subscription().subscriptionId

resource networkInterface 'Microsoft.Network/networkInterfaces@2022-11-01' = {
  location: location
  name: name
  properties: {
    dnsSettings: {
      dnsServers: (properties.?dnsServers ?? [])
    }
    disableTcpStateTracking: !(properties.?isTcpStateTrackingEnabled ?? true)
    enableAcceleratedNetworking: (properties.?isAcceleratedNetworkingEnabled ?? true)
    enableIPForwarding: (properties.?isIpForwardingEnabled ?? null)
    ipConfigurations: [for (configuration, index) in properties.ipConfigurations: {
      name: (configuration.?name ?? index)
      properties: {
        primary: (configuration.?isPrimary ?? (0 == index))
        privateIPAddress: (configuration.privateIpAddress.?value ?? null)
        privateIPAddressVersion: (configuration.privateIpAddress.?version ?? 'IPv4')
        privateIPAllocationMethod: (contains(configuration.privateIpAddress, 'value') ? 'Static' : 'Dynamic')
        publicIPAddress: (empty(configuration.?publicIpAddress ?? {}) ? null : { id: publicIpAddresses[index].id })
        subnet: { id: subnets[index].id }
      }
    }]
    networkSecurityGroup: (isNetworkSecurityGroupNotEmpty ? { id: networkSecurityGroup.id } : null)
    nicType: 'Standard'
  }
  tags: tags
}
resource networkSecurityGroup 'Microsoft.Compute/availabilitySets@2023-03-01' existing = if (isNetworkSecurityGroupNotEmpty) {
  name: properties.networkSecurityGroup.name
  scope: resourceGroup((properties.networkSecurityGroup.?subscriptionId ?? subscriptionId), (properties.networkSecurityGroup.?resourceGroupName ?? resourceGroupName))
}
resource publicIpAddresses 'Microsoft.Network/publicIPAddresses@2022-11-01' existing = [for configuration in properties.ipConfigurations: {
  name: configuration.publicIpAddress.name
  scope: resourceGroup((configuration.publicIpAddress.?subscriptionId ?? subscriptionId), (configuration.publicIpAddress.?resourceGroupName ?? resourceGroupName))
}]
resource subnets 'Microsoft.Network/virtualNetworks/subnets@2022-11-01' existing = [for configuration in properties.ipConfigurations: {
  name: '${configuration.privateIpAddress.subnet.virtualNetworkName}/${configuration.privateIpAddress.subnet.name}'
  scope: resourceGroup((configuration.privateIpAddress.?subscriptionId ?? subscriptionId), (configuration.privateIpAddress.?resourceGroupName ?? resourceGroupName))
}]

[slavizh]

@jeskew most likely can be closed?

[jeskew]

A fix for the underlying issue with resourceInfo was included in the w48 ARM release.