Azure Portal: languageVersion 2.0 `nullable` parameters are incorrectly marked as required

[jurjenoskam]

trafficstars

A parameter that is marked as nullable by using ? in the Bicep template will be incorrectly shown by the Azure Portal as a required parameter. (This is in the new functionality that was just introduced by the update that fixes #11096.)

To reproduce, publish the following (minimal but complete) Bicep template to a Template Spec and then try to deploy that Template Spec from the Portal:

param test string?
output test string = test ?? 'nothinghere'

You will notice that the Portal shows an * next to the parameter called Test, indicating that it is a required parameter. It will not accept leaving the input field empty, and refuse to deploy the template. There is no way to get the template output to be the string nothinghere (other than to supply exactly that string in the input field obviously).

Transpiling that template to ARM gives the following result. This is also the template that's shown when viewing the contents of the Template Spec.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "languageVersion": "2.0",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "0.26.54.24096",
      "templateHash": "15022646283098480590"
    }
  },
  "parameters": {
    "test": {
      "type": "string",
      "nullable": true
    }
  },
  "resources": {},
  "outputs": {
    "test": {
      "type": "string",
      "value": "[coalesce(parameters('test'), 'nothinghere')]"
    }
  }
}

[majastrz]

@jurjenoskam Are you able to set the parameter explicitly to null in the portal as a workaround?

[majastrz]

@stephaniezyen Can you triage this with the portal team?

[jurjenoskam]

@majastrz Unfortunately I haven't found a way to work around it, because anything you enter in the input field is not interpreted and simply becomes part of the literal contents of the string. For example, entering null in the input field results in a non-empty parameter value with the literal text null as its contents. Trying to supply an empty string also doesn't work, that just ends up a a string with literal "" or '' as its contents.

The same problem occurs in uiDefinition specifications by the way: if the uiDefinition does not explicitly output a value for a nullable parameter the Portal complains that the uiDefinition does not supply a value for all required parameters. Fortunately, in this case it is possible to supply a null value to the parameter as a workaround, as the uiDefinition is a JSON file you can choose whether to output a string or a null value. But for the standard deployment experience (without a custom uiDefinition) there doesn't seem to be a workaround.

[stephaniezyen]

Nullable is currently not supported in Custom Deployment. The Portal team has added this ask to their backlog, however no ETA on when this will be available.