fix: Add typed CIDR placeholders for unresolved address prefixes

[Jerome Brown (oWretch)]

Fixes #3907

Problem

When address prefixes are allocated at deployment time — for example by Azure Virtual Network Manager IPAM pools — reference() cannot resolve them during Bicep expansion. The unresolved property came back empty, and the empty value was then passed straight into cidrHost() / cidrSubnet():

cidrSubnet(reference('networkManager::platformPool').addressPrefixes[0], 23, 0)
> The specified CIDR '' is not valid.

cidrHost(reference('vnet::subnet').addressPrefixes[0], 3)
> The specified CIDR '' is not valid.

This makes it impossible to validate otherwise-correct templates that use IPAM-allocated address space.

Approach

Add a source-aware placeholder table in Mock.cs, keyed on resource type + normalized property path. When a property cannot be resolved, expansion now returns a typed mock value appropriate for that property rather than an empty one.

Covered today:

Resource type	Property path	Placeholder
Microsoft.Network/virtualNetworks	addressSpace.addressPrefixes	["192.0.2.0/24"]
Microsoft.Network/virtualNetworks/subnets	addressPrefix	"192.0.2.0/28"
Microsoft.Network/virtualNetworks/subnets	addressPrefixes	["192.0.2.0/28"]
Microsoft.Network/networkManagers/ipamPools	addressPrefixes	["192.0.2.0/24"]

Placeholders use RFC 5737 TEST-NET-1 (192.0.2.0/24) so they are obvious in output and cannot collide with real customer address space.

The table is the extension point — other resources with inferable properties (network interfaces, firewalls, DNS resolver endpoints, and so on) can be added later by adding rows, without further changes to the expansion code.

To make this work for both existing and deployed resources, resource type context is now carried through symbol lookup:

• IDeploymentSymbol gains TryGetResource, implemented by ObjectDeploymentSymbol and ArrayDeploymentSymbol, so symbol-only (existing) resources retain their type.
• MockResourceObject supplies typed placeholders for missing properties on a known resource while keeping normal object semantics, so partially-known properties objects don't lose resource type context.
• TemplateContext.TryGetResource keeps the _ResourceIds lookup authoritative (so module/deployment references still return a DeploymentValue), falling back to the symbol-attached resource.

The cidr*() functions stay strict

This deliberately does not relax cidrHost() / cidrSubnet(). Only indexed access into a placeholder array yields a CIDR string — MockResourcePropertyArray remains a MockArray. So genuine authoring mistakes still fail exactly as they do today:

• passing the wrong property, e.g. reference('vnet').id
• forgetting the index, e.g. addressPrefixes instead of addressPrefixes[0]
• singleton addressPrefix vs array addressPrefixes confusion

Additional fix: tryGet() on arrays

While validating against a wider set of real templates, found a related expansion failure with a different shape:

coalesce(
  tryGet(lambdaVariables('env').value, 'addressPrefixes'),
  lambdaVariables('env').value
)

Here env.value may be either an object with an addressPrefixes property, or an array of CIDR strings directly. ARM/Bicep tryGet(array, 'propertyName') should return null for an invalid property lookup so coalesce() falls back to the array, but PSRule threw:

Accessed JArray values with invalid key value: "addressPrefixes". Int32 array index expected.

ExpressionHelpers.TryPropertyOrField treated any non-JValue JToken, including JArray, as a property bag. Excluded JArray from that branch so it returns false for an array + string property, and Functions.TryGet() returns null as intended.

Testing

• New cases in FunctionTests.cs covering placeholder resolution, existing/deployed symbol resolution, that concrete values are still preferred over placeholders, and tryGet() returning null for an array.
• Full test suite green: 402 passed, 0 failed.
• Validated against real templates that previously failed expansion, including one using the tryGet/coalesce shape above; all now expand and evaluate cleanly.

[Engin Polat (polatengin)]

Thanks for this fix Jerome Brown (@oWretch).

Keeping the CIDR checks strict makes sense 👍

I found two cases that still give the empty-CIDR error:

• VNets with IPAM settings inside addressSpace , and Full references to deployed subnets.

The ID fallback also hides real errors, such as division by zero in a resource name.

Could you address these before we merge?

[Jerome Brown (oWretch)]

Engin Polat (@polatengin) addressed in 7111cfd:

• VNet IPAM inside addressSpace: concrete nested objects now retain their resource type and normalized property path, so a missing addressSpace.addressPrefixes resolves to the typed CIDR placeholder even when addressSpace.ipamPoolPrefixAllocations is present.
• Full references to deployed subnets: full resource mocks now wrap properties with the same source-aware context, so reference(..., 'Full').properties.addressPrefixes[0] resolves correctly.
• Hidden resource-name errors: narrowed both ID fallbacks from a broad catch to TemplateSymbolException. Expression evaluation errors such as div(1, 0) now propagate instead of being replaced by the symbolic name.

Regression coverage was added for all three cases. Full test suite: 402 passed, 0 failed.

[Elinora White (ElinoraWhite)]

Thank for the contribution Jerome Brown (@oWretch) LGTM.