[Bug Report]: Argument of type "null | string" is not assignable to parameter of type "string" warning on many modules

[shawntmeyer]

Describe the bug

Several child extensions report the subject error in VS Code mainly on the name property passed to the resource when using a reference to the parent. Here is an example from the resourceGroups nested_roleAssignments.bicep where the 'resourceId' specified in the name property is generating the error. This is just one example.

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for principalId in principalIds: {
  name: guid(last(split(resourceId, '/')), principalId, roleDefinitionIdOrName)
  properties: {
    description: description
    roleDefinitionId: contains(builtInRoleNames, roleDefinitionIdOrName) ? builtInRoleNames[roleDefinitionIdOrName] : roleDefinitionIdOrName
    principalId: principalId
    principalType: !empty(principalType) ? any(principalType) : null
    condition: !empty(condition) ? condition : null
    conditionVersion: !empty(conditionVersion) && !empty(condition) ? conditionVersion : null
    delegatedManagedIdentityResourceId: !empty(delegatedManagedIdentityResourceId) ? delegatedManagedIdentityResourceId : null
  }
}]

I am not sure if this is a new linter test in the BICEP extension, but there are two possibilities to mitigate this error.

1. Use the any() function to wrap the value of the referencing value (i.e., 'guid(any(last(split(resourceId, '/'))), principalId, roleDefinitionIdOrName)').

name: guid(any(last(split(resourceId, '/'))), principalId, roleDefinitionIdOrName)

2. Use a non-null assertion postfix operator (!) just introduced in BICEP (but not documented as of now) that tells the linter that we will never have a null value for this passed variable.

name: guid(last(split(resourceId, '/'))!, principalId, roleDefinitionIdOrName)

For more information see: Azure\BICEP Github Issue #9565 and
Azure\BICEP Github Pull Request #9585.

To reproduce

Open modules\Microsoft.Resources\resourceGroups.bicep\nested_roleAssignments.bicep in Visual Studio Code and navigate to line 229. The error looks like this:

Note that this is not the only occurrence.

Code snippet

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for principalId in principalIds: {
  name: guid(last(split(resourceId, '/')), principalId, roleDefinitionIdOrName)
  properties: {
    description: description
    roleDefinitionId: contains(builtInRoleNames, roleDefinitionIdOrName) ? builtInRoleNames[roleDefinitionIdOrName] : roleDefinitionIdOrName
    principalId: principalId
    principalType: !empty(principalType) ? any(principalType) : null
    condition: !empty(condition) ? condition : null
    conditionVersion: !empty(conditionVersion) && !empty(condition) ? conditionVersion : null
    delegatedManagedIdentityResourceId: !empty(delegatedManagedIdentityResourceId) ? delegatedManagedIdentityResourceId : null
  }
}]

Relevant log output

No response

[AlexanderSehr]

Note: In the ResourceGroup module, this VSCode warning actually shows up as an error

[shawntmeyer]

My vote is to use the Postfix operator. The BICEP extension actually suggests this fix. See:

[AlexanderSehr]

Note: I just tested it with the RG module and at least there - it doesn't work.

If I add the !, the VSCode error goes away - but az bicep build throws an error when compiling:

ERROR: C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\deploy.bicep(59,38) : Error BCP104: The referenced module has errors.
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(228,10) : Warning BCP179: Unique resource or deployment name is required when looping. The loop item variable "principalId" must be referenced in at least one of the value expressions of the following properties: "name", "scope"
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(229,42) : Error BCP236: Expected a new line or comma character at this location.
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(229,43) : Error BCP009: Expected a literal value, an array, an object, a parenthesized expression, or a function call at this location.

If I remove it again, the VSCode extension error is back - but the compilation works again. Will comment on the Bicep issue

[shawntmeyer]

Note: I just tested it with the RG module and at least there - it doesn't work.

If I add the !, the VSCode error goes away - but az bicep build throws an error when compiling:

ERROR: C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\deploy.bicep(59,38) : Error BCP104: The referenced module has errors.
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(228,10) : Warning BCP179: Unique resource or deployment name is required when looping. The loop item variable "principalId" must be referenced in at least one of the value expressions of the following properties: "name", "scope"
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(229,42) : Error BCP236: Expected a new line or comma character at this location.
C:\dev\ip\DevOps-Self-Hosted\AlexanderSehr-Fork\CARML0.9\Microsoft.Resources\resourceGroups\.bicep\nested_roleAssignments.bicep(229,43) : Error BCP009: Expected a literal value, an array, an object, a parenthesized expression, or a function call at this location.

If I remove it again, the VSCode extension error is back - but the compilation works again. Will comment on the Bicep issue

what happens if you try the any() method?

[AlexanderSehr]

Just upgraded Bicep to 0.14.6 too - there the ! doesn't cause any issues. Any() should work without an issue as it works differently from !.

This puts us into a tough spot as the GitHub Runners are still operating 0.13.1 which doesn't work with that fix (as per the error message above). So if we upgrade to the fix - then our pipelines will start failing on some of the modules (like ResourceGroup).

[shawntmeyer]

Just upgraded Bicep to 0.14.6 too - there the ! doesn't cause any issues. Any() should work without an issue as it works differently from !.

This puts us into a tough spot as the GitHub Runners are still operating 0.13.1 which doesn't work with that fix (as per the error message above). So if we upgrade to the fix - then our pipelines will start failing on some of the modules (like ResourceGroup).

yeah, the ! is a new implementation (2 weeks ago :))

[AlexanderSehr]

Right. I think before we can fix this we need to wait for the GitHub runners to update. It's a breaking change otherwise

[krbar]

We should keep the ADO build agents in mind, which may also use the 0.13.1

[shawntmeyer]

Is there a document outlining the release schedule for the agents in both ADO and GitHub?

[AlexanderSehr]

Not as far as I know.

An additional note: When running 0.14.6 - the Linter rule will always be a warning until we updated the modules. The one exception I'm aware of is the ResourceGroup that actually throws an error. So it will also throw an error for any customer that uses our module until it is 'updated'.

[eriqua]

We definitely need to prioritize a fix for the error thrown by Bicep release 0.14.6. Luckily it should be easy, let's use the rg resourceId in the guid instead of using last and split functions to calculate the name, that would also be more consistent with the way other rbac deployments are done at resource scope.

For the bigger picture on how to fix the warning for all rbac at resource scope, we should discuss it more thoroughly. Discuss if we want to support both versions 0.13.1 and 0.14.6, or if going with the latest and update 0.14.6 on both gh runners and ADO agents. Another point would be to add to the CARML release the Bicep version with which that was tested.

[eriqua]

Not as far as I know.

An additional note: When running 0.14.6 - the Linter rule will always be a warning until we updated the modules. The one exception I'm aware of is the ResourceGroup that actually throws an error. So it will also throw an error for any customer that uses our module until it is 'updated'.

This should cover the error on RG RBAC #2642