Bicep script overwrites/reset instance specific settings after Azure App Service slot swap

[andsj073]

Rerunning a Bicep script - that declares an App having at least one deployment slot App - after a slot swap action, resets any and all instance specific settings in all slots, thus breaking runtime functionality.

The reason is that a deployment state changing action (the slot swap) is performed outside of the Bicep realm which is declarative and enforces a desired state.

Schematically

	Env. state after first Bicep run	Env. state after slot swap	Env. state after rerun of Bicep
App	myFunctionApp	myFunctionApp	myFunctionApp
Production slot	Production	Production	Production
App instance in production slot	1	2	2
Value of SettingA on the instance in production slot	X	Y	X
Staging slot	Staging	Staging	Staging
App instance in staging slot	2	1	1
Value of SettingA on the instance in staging slot	Y	X	Y
Result	Ok	Ok	Not ok, resetting X and Y breaks runtime behavior

Example Bicep declaration

In particular SettingA could be WEBSITE_CONTENTSHARE pointing out the file share where the deployed code, assemblies etc reside. This setting and its instance-unique value follows its instance to the slot during swap, but later a new run of the Bicep resets the value which breaks the runtime of production slot.

resource myFunctionApp 'Microsoft.Web/sites@2023-01-01' = {
  name: myFunctionAppName
  location: location
  kind: 'functionapp'
  properties: {
    siteConfig: {
      appSettings: [
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: 'Green'
        }
      ]
    }
  }
}

resource myFunctionAppStaging 'Microsoft.Web/sites/slots@2023-01-01' = {
  parent: myFunctionApp
  name: 'staging'
  location: location
  kind: 'functionapp'
  properties: {
    siteConfig: {
      appSettings: [
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: 'Blue'
        }
      ]
    }
  }
}

Resolution?

Surely, there must be many people that have struggled with this already. I can't find anything about it though. What is the best way to solve this?

I realize that a hack could be to read (using Bicep) any existing settings of the deployed production App and implement some logic to find existing Production settings that should not be reset during Bicep deployment.

But is that really the way? Seems ugly, cumbersome and brittle.

Much grateful for any ideas!