@danielstocker Thank you so much for bringing this to our attention. I have this assigned to the service lead to be investigated further and will make an update when we have greater clarity.

@Mike-Ubezzi-MSFT @mike-urnun-msft

Thanks for looking into this.

Do you need any more information to progress this?

@danielstocker can you provide more background about what was your original issue which leads to this discovery? I am not sure to properly understand the implication to set it improperly (what you mentioned as an unintentional swap)

Hi @ggirard07,

No problem. Let me summarise.
This came up initially because our documentation states that WEBSITE_CONTENTSHARE is required. (see here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)

If we export a Functions template from the Marketplace (export template on the last page) we get WEBSITE_CONTENTSHARE as a standard app setting. If we use this, then the following situation can happen.

1. We deploy an ARM template and get an empty function with two slots
2. We deploy to the staging slot
3. We swap to make the content available in production
4. UNINTENDED SWAP as the ARM template is redeployed and app settings are reapplied (this even happens during an incremental ARM deployment as the appsettings resource always overwrites and resets the WEBSITE_CONTENTSHARE setting)
5. Deployment routine now deploys the new code to the staging slot and our production slot is empty rather than containing the previous version. Our production function is "unintentionally" down

The customer in this particular case then pointed to this article https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/

This suggests that the setting should be set as a slot setting to fix the behaviour. While this does fix the behaviour in my tests, it seems wrong, because it should not work.

Below is a table of what happened in my tests. (after making it a slot setting)

My (and the customer's) perception is that the slots should not swap at all anymore, but as described in the article, it still works anyway.

I raised this internally as well and people found inconsistent behaviour when changing app settings. (Hence why this is highlighted in my testing grid) For a colleague testing it, updating the app settings, made the slot settings re-apply thus again causing an unintended swap.

This then finally (sorry about the lengthy response) led me to raise the support case where the outcome was "just do not set the setting at all".
My personal tests showed that this does fix the issue, but there is no guidance in the documentation to confirm this, hence why I raised this item.

Hope this helps.
Let me know if anything is unclear.

@danielstocker definitively an important information, especially to understand how the slots and swapping are working for Functions vs a traditional webapp with webjobs.
Also this is not explained either in the slots documentation despite 'WEBSITE_CONTENTSHARE' playing a critical role here. There is only a single screenshot at step 4 representing it, where those values are truncated to make things even more clear...

Hi @ggirard07 and thanks for reading through my diatribe. So what's the way forward from here? :)

@ggirard07 @ggailey777 @mike-urnun-msft

Is more information required to create some documentation clarity around this behaviour? I'm working with a customer who is considering stopping to use function slots because they are unsure about the official guidance around this scenario.

Thanks for your help

@danielstocker Just so that I am clear on what you think will address the documentation issues related to this:

• Remove the WEBSITE_CONTENTSHARE deployment setting from here.
• Add a note in the reference article that WEBSITE_CONTENTSHARE should only be set by the runtime.

Do you think that would be sufficient?

cc. @mattchenderson

Hi @ggailey777
Yes I think that'd be a good solution

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

If it isn't applied then the runtime will generate one for you, i think.

I deployed an ARM with a Consumption-plan and a Function App with a section Microsoft.Web/sites/config named appsettings and the following properties

• FUNCTIONS_EXTENSION_VERSION : "~2",
• FUNCTIONS_WORKER_RUNTIME : "dotnet",
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [storage connectionstring]
• WEBSITE_NODE_DEFAULT_VERSION: 6.5.0

The deployment returned the following error:

      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

After I also removed parameter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, the deployment went without any errors. So, there seems to be some required relation between those two settings.
Although successful, this deployment made me wander if and where function (packages) are physically deployed (and if this case is valid in the first place).

We have been seeing the exact behavior @tjgalama has described and are also wondering where the file shares with the function packages are stored.

Our function apps also include a timer triggered function, so we specify the AzureWebJobsStorage setting as suggested: we would have guessed/hoped the runtime would have used that same connection string for the (now implicit) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, but that isn't the case: in the storage account we specify there, we do see the azure-webjobs-hosts and azure-webjobs-secrets blob containers, but no file shares are present.

I have checked in Kudu for clues and it looks like all the files that needs to be there are in the file system (wherever that is, checked on app-name.scm.azurewebsites.net/api/vfs/), but no reference to either settings (WEBSITE_CONTENTSHARE or WEBSITE_CONTENTAZUREFILECONNECTIONSTRING) is to be seen in the environment tab (appname.scm.azurewebsites.net/Env.cshtml).

Maybe important to mention, our apps are set up with WEBSITE_ENABLE_SYNC_UPDATE_SITE=True and WEBSITE_RUN_FROM_PACKAGE=1.
The apps seem to work, but we would really like some clarity on this point, as we are porting a core business service to Azure Functions and want to figure this one out before rolling out to production.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

We have noticed this same issue over the past few days and need guidance on how to proceed. We have also been following the approach of setting the WEBSITE_CONTENTSHARE as a slot setting to get around the unintentional swap issue but now can't deploy due to this error. I have tried retroactively removing both this and the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING settings to move towards what appears to be the recommended approach of not using either, but these deployments would also fail.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

Remove it and let the runtime pick a name. Thid is how I do it.

I have tried so many combinations of these properties now and I recently managed to wipe everything in my function. What would be the negative consequence of always setting both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in ARM and using different values in WEBSITE_CONTENTSHARE for different slots, ie "share1", "share2" etc?

In our setup we only modify the staging slot from the ARM template (leaving the production slot untouched) and then perform an automatic swap after code deployment. We sorted this issue using this setup:

                "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('functionAppStorageAccountName'), ';AccountKey=', listKeys(parameters('functionAppStorageAccountName'),'2019-06-01').keys[0].value)]",
                "WEBSITE_CONTENTSHARE": "[uniqueString(resourceGroup().id, deployment().name)]",

This ensures that each new deployment gets a valid but unique WEBSITE_CONTENTSHARE string which doesnt interfer with the primary (production) slot.

@shubDhond Can we also have some guidance on what to do when the deployment is via Linux docker container on Elastic Premium - it seems to require the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENSHARE to host the Kudu environment even it's not being used for the functions themselves; if the file share doesn't exist then the host doesn't even start (can provide support ticket references if needed)

@akoz0r is this the same thing as it should work out of the box? That each release to the slot gets its own unique CONTENTSHARE folder?

Here is a (currently) working ARM Template for Consumption plan when WEBSITE_RUN_FROM_PACKAGE is set to 1 with a deployment slot without specifying the WEBSITE_CONTENSHARE property:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "appName": {
      "type": "string"
    }
  },
  "variables": {
    "functionAppName": "[parameters('appName')]",
    "hostingPlanName": "[parameters('appName')]",
    "applicationInsightsName": "[parameters('appName')]",
    "storageAccountName": "[parameters('appName')]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[variables('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "kind": "StorageV2",
      "sku": {
        "name": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2018-02-01",
      "name": "[variables('hostingPlanName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Y1",
        "tier": "Dynamic"
      },
      "properties": {
        "name": "[variables('hostingPlanName')]",
        "computeMode": "Dynamic"
      }
    },
    {
      "type": "Microsoft.Insights/components",
      "apiVersion": "2015-05-01",
      "name": "[variables('applicationInsightsName')]",
      "location": "[resourceGroup().location]",
      "kind": "web",
      "properties": {
        "Application_Type": "web",
        "ApplicationId": "[variables('applicationInsightsName')]"
      },
      "tags": {
        "[concat('hidden-link:', resourceGroup().id, '/providers/Microsoft.Web/sites/', variables('functionAppName'))]": "Resource"
      }
    },
    {
      "type": "Microsoft.Web/sites",
      "name": "[variables('functionAppName')]",
      "apiVersion": "2018-11-01",
      "location": "[resourceGroup().location]",
      "kind": "functionapp",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
        "[resourceId('Microsoft.Insights/components', variables('applicationInsightsName'))]"
      ],
      "properties": {
        "name": "[variables('functionAppName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "node"
            },
            {
              "name": "WEBSITE_NODE_DEFAULT_VERSION",
              "value": "~12"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            },
            {
              "name": "AzureWebJobsStorage",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "APPINSIGHTS_INSTRUMENTATIONKEY",
              "value": "[reference(resourceId('microsoft.insights/components/', variables('applicationInsightsName')), '2015-05-01').InstrumentationKey]"
            },
            {
              "name": "NODE_ENV",
              "value": "production"
            }
          ]
        }
      },
      "resources": [
        {
          "type": "config",
          "apiVersion": "2018-11-01",
          "name": "slotConfigNames",
          "dependsOn": [
            "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
          ],
          "tags": {
            "displayName": "slotConfigNames"
          },
          "properties": {
            "storageAccountUrl": "",
            "appSettingNames": [
              "NODE_ENV"
            ]
          }
        },
        {
          "type": "slots",
          "apiVersion": "2018-11-01",
          "name": "staging",
          "location": "[resourceGroup().location]",
          "dependsOn": [
            "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
          ],
          "properties": {
            "siteConfig": {
              "appSettings": [
                {
                  "name": "FUNCTIONS_EXTENSION_VERSION",
                  "value": "~3"
                },
                {
                  "name": "FUNCTIONS_WORKER_RUNTIME",
                  "value": "node"
                },
                {
                  "name": "WEBSITE_NODE_DEFAULT_VERSION",
                  "value": "~12"
                },
                {
                  "name": "WEBSITE_RUN_FROM_PACKAGE",
                  "value": "1"
                },
                {
                  "name": "AzureWebJobsStorage",
                  "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
                },
                {
                  "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
                  "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
                },
                {
                  "name": "APPINSIGHTS_INSTRUMENTATIONKEY",
                  "value": "[reference(resourceId('microsoft.insights/components/', variables('applicationInsightsName')), '2015-05-01').InstrumentationKey]"
                },
                {
                  "name": "NODE_ENV",
                  "value": "staging"
                }
              ]
            }
          }
        }
      ]
    }
  ]
}

You have to provide the appsettings in the functionapp's properties/siteConfig/appSettings object instead of using the config type. Otherwise, you would get the Required parameter WEBSITE_CONTENTSHARE is missing. error message.

app plan kind: Linux
tier: Dynamic
os_type: linux
version: ~2

I'm getting this error when doing a swap slot

##[error]Error: Failed to swap App Service 'test-dev-func-we' slots - 'slot1' and 'production'. Error: InternalServerError - There was an unexpected error swapping slots 'slot1' and 'production' for site 'test-dev-func-we(slot1)'. Please try to cancel your swap operation. (CODE: 500)

Looking on azure for diagnosis of the failure:

Though according to the docs:
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
WEBSITE_CONTENTSHARE
Only used when deploying to a Premium plan or to a Consumption plan running on Windows. Not supported for Consumptions plans running Linux.

I am running a consumption based function app on Linux. This app setting should not apply to the function app I am deploying. Why am I getting the error above during performing a swap slot? Any help would be appreciated.

Note, when modifying an existing function, and you get Bad Request, try using a valid storage account file name, i.e. lowercase!

Also, not sure this is intended, but after moving to File storage, it only affects slot 0. slot 1+ will need the connection string and share name added as well! For now we are not proceeding to do this as our slot is a staging slot, and by moving to a storage account file share, we are unable to list the function and run them manually! Staging does not need to be scaled at this time, though it would be nice to list and run functions anywhere.

I'm using the Portal and not a template. Deleting WEBSITE_CONTENTSHARE doesn't seem to work; the old value remains.

Consumption plan. Windows.

What can I do about this? Swapping can't work for me right now.

@danielstocker, I have removed WEBSITE_CONTENTSHARE from my arm template. However, still below behavior observed when I run arm template (even without any change) and then deploy function app code(which you mentioned as point 5)

4. UNINTENDED SWAP as the ARM template is redeployed and app settings are reapplied (this even happens during an incremental ARM deployment as the appsettings resource always overwrites and resets the WEBSITE_CONTENTSHARE setting)
5. Deployment routine now deploys the new code to the staging slot and our production slot is empty rather than containing the previous version. Our production function is "unintentionally" down

Would like to mention that its not swap rather its clear deployment on production slot (getting 404 error)when i run full pipeline (ARM template and then deploy code). Please suggest

@danielstocker, Any suggestion on this issue.

@realrubberduckdev or @ggailey777 may be more able to comment here.

While I created the original issue over a year ago, I have not actively worked on this problem for some time.

Based on your description @manish1653 I can’t comment on what the expected behavior is today as the components involved have all moved on. (several years of code changes)

It might be more sensible to create a fresh issue referencing my summary.

Thank you @danielstocker.

@realrubberduckdev,@ggailey777 - Do I need to create a new ticket for this problem?
Also, For more information, I am using "apiVersion": "2015-08-01" for app (type - Microsoft.Web/sites). In short, This is my ARM code:
{
"apiVersion": "2018-02-01",
"location": "[parameters('location')]",
"name": "[variables('testApiFunctionName')]",
"properties": {
"name": "[variables('testApiFunctionName')]",
"computeMode": "Dynamic"
},
"sku": {
"name": "Y1",
"tier": "Dynamic"
},
"type": "Microsoft.Web/serverfarms"
},
{
"apiVersion": "2015-08-01",
"type": "Microsoft.Web/sites",
"name": "[variables('testApiFunctionName')]",
"location": "[parameters('location')]",
"kind": "functionapp",
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('testApiFunctionName'))]",
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
],
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('testApiFunctionName'))]",
"siteConfig": {
"appSettings": [
{
"name": "AzureWebJobsDashboard",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "AzureWebJobsStorage",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "FUNCTIONS_EXTENSION_VERSION",
"value": "~2.0"
},
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "[parameters('appInsightsInstrumentationKey')]"
},
{
"name": "FUNCTIONS_WORKER_RUNTIME",
"value": "dotnet"
}
]
}
}
},

@manish1635 your description sounds similar to what @danielstocker has described above. Although I agree that, given the length of this thread, it is possibly easier for anyone investigating if you create a fresh new issue with steps on how to reproduce this. Referencing this issue will help I think. Good luck :-)

Hi @realrubberduckdev, Created a new issue: #82452

I am also facing this issue using a Premium plan where WEBSITE_CONTENT* are required, and don't have a clear path forward.

@robinhultman

I have tried so many combinations of these properties now and I recently managed to wipe everything in my function. What would be the negative consequence of always setting both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in ARM and using different values in WEBSITE_CONTENTSHARE for different slots, ie "share1", "share2" etc?

This approach also suffers from the same problem upon redeployment. How do you know when to set production slot with share1 or share2?

@akoz0r

This ensures that each new deployment gets a valid but unique WEBSITE_CONTENTSHARE string which doesnt interfer with the primary (production) slot.

Wouldn't this mean the storage account will start piling up with several file shares, unless you manually go in and delete the unused ones?

I am also facing this issue using a Premium plan where WEBSITE_CONTENT* are required, and don't have a clear path forward.

@robinhultman

I have tried so many combinations of these properties now and I recently managed to wipe everything in my function. What would be the negative consequence of always setting both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in ARM and using different values in WEBSITE_CONTENTSHARE for different slots, ie "share1", "share2" etc?

This approach also suffers from the same problem upon redeployment. How do you know when to set production slot with share1 or share2?

@akoz0r

This ensures that each new deployment gets a valid but unique WEBSITE_CONTENTSHARE string which doesnt interfer with the primary (production) slot.

Wouldn't this mean the storage account will start piling up with several file shares, unless you manually go in and delete the unused ones?

yup!

I finally figured this issue out with using these 2 settings: WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.

Here's what i did to make it work

1. In your main site's app settings, set both of these settings.
   WEBSITE_CONTENTSHARE points to a share in the storage account (in my case, i create this share in the ARM template). Example: 'myfunctionapp011'
   WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: should be set to connection string of the storage account that contains the fileshare pointed to by WEBSITE_CONTENTSHARE

2. DO NOT set these 2 app settings in your slot's app settings.

3. If you have your storage account integrated to the same vnet/subnet as your function app, be sure to set the following app setting in BOTH main site and slot's app settings:

"WEBSITE_CONTENTOVERVNET": "1"

Also, set "vnetRouteAllEnabled": true in both slot and main site to ensure traffic goes through your vnet.

Hope it helps!

@hb66772-home Won't WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING be replaced with nothing during the swap if you don't set it in the slot settings?

using the latest provider v2.97.0 I can see these two values are set correctly for a elastic premium plan. great.

I also tested on a dedicated plan, P1v2 and P1v3 , the settings are not applied to main production slot, however they are created for the staging slot? ( azurerm_function_app_slot ) has the same coding not been applied?

I have the following code:

var appSettings = [
  {
    name: 'WEBSITE_ENABLE_SYNC_UPDATE_SITE'
    value: 1
  }
  {
    name: 'SCM_TOUCH_WEBCONFIG_AFTER_DEPLOYMENT'
    value: 0
  }
  {
    name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
    value: reference(resourceId(appInsightsResourceGroup, 'microsoft.insights/components/', appInsightsName), '2015-05-01').InstrumentationKey
  }
  {
    name: 'AzureWebJobsStorage'
    value: 'storageAccount'
  }
  {
    name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
    value: 'connectionstring'
  }
  {
    name: 'FUNCTIONS_WORKER_RUNTIME'
    value: 'dotnet'
  }
  {
    name: 'FUNCTIONS_EXTENSION_VERSION'
    value: '~4'
  }
]

var stagingSettings = [
  {
    name: 'WEBSITE_CONTENTSHARE'
    value: toLower('functionApp-staging')
  }
  {
    name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
    value: 'hubStaging'
  }
]

var productionSettings = [
  {
    name: 'WEBSITE_CONTENTSHARE'
    value: toLower('functionApp')
  }
  {
    name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
    value: 'hub'
  }
]

module functionAppTemplate 'functionApp.bicep' = {
  name: 'functionAppTemplate'
  params: {
    name: '${functionAppName}'
    kind: functionAppKind
    location: location
    servicePlanName: servicePlanName
    secretSettings: union(appSettings, productionSettings)
  }
  dependsOn: [
    servicePlanTemplate
  ]
}

module functionAppSlotTemplate 'functionAppSlot.bicep' = {
  name: 'functionAppSlotTemplate'
  params: {
    name: '${functionAppName}/staging'
    kind: functionAppKind
    location: location
    servicePlanName: servicePlanName
    secretSettings: union(appSettings, stagingSettings)
  }
  dependsOn: [
    functionAppTemplate
  ]
}

functionApp.bicep

resource functionApp 'Microsoft.Web/sites@2018-02-01' = {
  name: name
  location: location
  kind: kind
  properties: {
    serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
    clientAffinityEnabled: false
    httpsOnly: true
    siteConfig: {
      use32BitWorkerProcess : false
      appSettings: secretSettings
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

functionAppSlot.bicep

resource functionAppSlot 'Microsoft.Web/sites/slots@2018-11-01' = {
  name: name
  kind: kind
  location: location
  properties: {
    clientAffinityEnabled: true
    enabled: true
    httpsOnly: true
    serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
    siteConfig: {
      use32BitWorkerProcess : false
      appSettings: secretSettings
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

With this, I see the functions in production slot getting removed during deployment. What am I missing?

My The parameter WEBSITE_CONTENTSHARE has an invalid value error was actually caused because my Function App name had the word "FunctionApp" and is a reserved word I guess. So bad idea to use "MyFunctionAppTest" or things like that and specially to assign the same name to the WEBSITE_CONTENTSHARE value.

The docs should now be correct and hopefully helpful on this issue. Please reopen or create a new issue if you find that is not the case. #please-close