The language expression property 'administratorLoginPassword' doesn't exist

[ielcoro]

Bicep version
Bicep CLI version 0.3.539 (c8b397d)

Describe the bug
After declaring a SQL Database Server resource, intelisense allows you to select incorrectly from output of the resource the property administratorLoginPassword. However this property does not exist on the output, when deployin the template (the build also allows it), you are given the following error:

The language expression property 'administratorLoginPassword' doesn't exist

To Reproduce
Create a Sql Sever resource inside a bicep template:

resource db_server 'Microsoft.Sql/servers@2020-11-01-preview' = {
  name: server_name
  location: resourceGroup().location
  tags: resourceGroup().tags
  properties: {
    administratorLogin: database_login
    administratorLoginPassword: database_password
    version: '12.0'
    publicNetworkAccess: 'Enabled'
  }
}

Use the administratorLoginPassword in any other place in the template:

var password string = db_server.administratorLoginPassword

It will allow it while on VS Code or build, but it will fail on deployment.

[alex-frankel]

Good catch - this should be marked as a secret property in swagger, but it must not be. Can you add this to #784?

[alexgman]

so what do we do if we need to use administratorLoginPassword in an ARM template??

[alex-frankel]

@bmoore-msft do you happen to know if there is a list*() function for sql/servers? I looked in our reference doc and don't see anything.

[bmoore-msft]

Nothing I can find either - but it would be rare that you can retrieve a login creds via POST (I know some resources do it).

Though not sure I understand the scenario... if you need to use the pw in the template, why wouldn't you just use the database_password parameter (or keyVault)?

[ielcoro]

You could do it that way, but for simplicity when returning the output from the bicep execution we return the resources created, and as that property is defined in the resource, we expected it to be read.

However the problem I´m reporting has more to do with the fact that VS Code intellisense allows to reference it and it only fails on build, than with the fact that we can workaround its usage by passing the parameter when needed. Allowing you to choose from intellisense a property that then will fail on build is distracting and causes trust issues with the suggestions.

[bmoore-msft]

got it... so the reference expression is created during bicep build isn't valid as that property is not part of a GET response?

@alex-frankel do we do any type checking when we create the runtime reference? Seems like either a swagger issue or we could do that checking during build (and at least warn the property isn't found)

[alex-frankel]

Yeah I believe it's a swagger issue. We consider it to be a readable property, but it should be marked as a secret, so we don't show it.

@anthony-c-martin - can you confirm? I assume this is how we are handling properly marked secrets, but don't know for sure.

[anthony-c-martin]

The Bicep type generation doesn't understand the mutability extensions:
https://github.com/Azure/azure-rest-api-specs/blob/88e7838a09868a51de3894114355c75929847a46/specification/sql/resource-manager/Microsoft.Sql/preview/2021-02-01-preview/Servers.json#L449-L452

Tracked by Azure/bicep-types-az#240

[anthony-c-martin]

Closed by Azure/bicep-types-az#436 - this should be fixed in the next Bicep release.