Validate `scope` property for known values at compile-time
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 21m
- Merged PRs (30d)
- 79
Description
**Bicep version**
0.17.1
**Describe the bug**
I'll admit this is a bizarre one. I was getting this structure when retrieving the `.id` property of an existing private DNS zone:
`/subscriptions/subscriptions//...`
(Note the duplicated `/subscriptions` in the front.)
I could not figure out why, until I realized that I explicitly referenced the DNS zone like this (some pseudo code):
```bicep
resource rg resourceGroups existing = {
name: 'rgname'
scope: subscription(**idparam**)
}
resource dnsZone privateDnsZones existing = {
name: 'privatelink....'
scope: rg
}
```
It turns out that I used the `subscription().id` function somewhere else to populate the value of `idparam`; I should have used the `subscription().subscriptionId` property instead.
**To Reproduce**
Included in description above, I believe.
**Additional context**
This is obviously my mistake, but it seems that referencing a resource group with a subscription ID that is incorrectly formatted shouldn't be possible. This error didn't manifest itself until I subsequently tried to use `dnsZone.id` somewhere else to register a private endpoint.
Contributor guide
Research direction
Start from the Bicep handling of the resource `scope` property and the `subscription()` values described in the reproduction. Trace how an incorrectly formatted subscription identifier reaches the private DNS zone resource, then verify that invalid scope values are rejected at compile time rather than producing a malformed `.id`.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100