Oddities with parameter values

[SvenAelterman]

I am looking for some help understanding what could be causing this behavior.

I am working on a set of Bicep modules, one of which references a (local) CARML module for Application Gateway. I don't know if the behavior I am seeing is limited to just this module, but that's where it's showing up.

The CARML module for App GW has complex parameters (essentially the object model of the API to create listeners, HTTP settings, routing rules, etc.).

With Bicep 0.24.24 (and maybe earlier versions, I am just observing it for the last few days on a colleague's machine), when we change a value of a parameter, on the next deployments, old parameter values are being used.

A specific example was when we created a resource ID to reference an aspect of the App GW and accidentally used '/subscriptions/subscription().id)/...' instead of subscription().subscriptionId. This resulted in the resource ID looking like this at runtime: /subscriptions//subscriptions/0000-.../.... We fixed the mistake in Bicep and ran a new deployment... but the parameter value still had the incorrect ID format. And on the next deployment, etc.

It might be relevant that this value was deeply nested in the params, like so:

module ...
  params: {
    redirectConfigurations: [
      {
        name: '${redirectNamePrefix}${workloadName}'
        properties: {
          redirectType: 'Permanent'
          includePath: true
          includeQueryString: true
          requestRoutingRules: [
            {
              // HERE IS WHERE THE BEHAVIOR OCCURS. THIS VALUE STILL STARTS WITH /subscriptions//subscriptions/0000... EVEN THOUGH THE BUG HAS LONG BEEN FIXED.
              id: '${subscription().id}/resourceGroups/${vnetResourceGroupName}/providers/Microsoft.Network/applicationGateways/${applicationGateWayName}/requestRoutingRules/${routingRuleNamePrefix}${workloadName}${redirectRoutingRuleNameSuffix}'

              //     //id: '${appGwExpectedResourceId}/requestRoutingRules/${routingRuleNamePrefix}${workloadName}${redirectRoutingRuleNameSuffix}'
            }
          ]
          targetListener: {
            id: '${subscription().id}/resourceGroups/${vnetResourceGroupName}/providers/Microsoft.Network/applicationGateways/${applicationGateWayName}/httpListeners/${httpListenerNamePrefix}-${workloadName}'
          }
        }
      } ]
  }

Note, this is just one example, it has been happening for other property values too.

We thought that maybe changing the deployment name resolved it, but that's not the case. We also tried restarting Visual Studio Code.

It's as if something is cached somewhere that isn't being cleared correctly. I have no idea where to start looking to troubleshoot this.

Has anyone else observed this and found a solution for it?

[anthony-c-martin]

Bicep caches registry modules to ~/.bicep - I believe this is the only persistent caching that we do. Could you retry deploying after running bicep restore --force <path_to_your_bicep_file>?

[SvenAelterman]

We're not using the CARML module from a registry though. It's locally downloaded and in a subfolder.