@onlyIfNotExists() does not work on Microsoft.NetApp/netAppAccounts/capacityPools/volumes/snapshots

[slavizh]

Bicep version
Bicep CLI version 0.46.1 (545b338)

Describe the bug
Snapshots are one time deployment resources. If re-deployed they give you: There already exists a snapshot with name . Event when @onlyIfNotExists() decorator is applied the error is still given so for some reason the decorator does not work for those type of resources.

To Reproduce
Steps to reproduce the behavior:

param snapshot object
param netAppAccountName string
param netAppPoolName string
param netAppVolumeName string

resource netAppVolumeRes 'Microsoft.NetApp/netAppAccounts/capacityPools/volumes@2026-05-15-preview' existing = {
  name: '${netAppAccountName}/${netAppPoolName}/${netAppVolumeName}'
}

@onlyIfNotExists()
resource snapshots 'Microsoft.NetApp/netAppAccounts/capacityPools/volumes/snapshots@2026-05-15-preview' =  {
  name: snapshot.name
  parent: netAppVolumeRes
  location: resourceGroup().location
  properties: {}
}

Additional context
Add any other context about the problem here.

[torreymicrosoft]

Thanks for the report, and for including a complete repro along with the version. That made this much faster to look at.

I started with the Bicep side. On 0.46.1 your template compiles cleanly and the decorator does reach the output:

JSON

"snapshots": {
  "@options": {
    "onlyIfNotExists": []
  },
  "type": "Microsoft.NetApp/netAppAccounts/capacityPools/volumes/snapshots",
  "apiVersion": "2026-05-15-preview",
  ...
}

To check whether something about this particular resource type was causing the decorator to be dropped, I compiled the same decorator onto a plain Microsoft.Storage/storageAccounts resource and got an identical "@options": { "onlyIfNotExists": [] }. As a control I compiled a deliberately invalid decorator name as well, which failed with BCP057, so the clean result above is a real pass rather than a check that never fired.

I also ruled out the failure mode from #18603, where this feature errors out unless the template language version is set. Your build emits "languageVersion": "2.0", so that is not what you are running into.

That puts the compiler in the clear and points at how the deployment engine evaluates the option for this type.

The mechanism is the part that matters for your case. On #18226 the resolution was that the check is keyed on resource ID: when the resource ID already exists the deployment reads instead of writes. So the decorator only suppresses the write when the ID computed from your template matches the ID of the snapshot that is already there.

There are three things I cannot get from the template alone, and with them I can take this further:

1. The correlation ID from a failed deployment, plus the full error body rather than the message on its own.

2. The full resource ID of the snapshot that already exists, from az resource show, so it can be compared against what the template computes, which resolves to <account>/<pool>/<volume>/<snapshot.name>.

3. The value of snapshot.name on the run that failed.

If those two IDs differ in any way, that explains the behaviour and makes this an ID shape problem rather than a broken decorator. If they match exactly, then the option is being ignored for this resource type, which is a more significant bug and worth tracking alongside #18454, where the same theme is open for role assignments.

This is an automated first-pass triage reply from the Azure ARM Deployments team, drafted with AI assistance. It is intake rather than a final answer, and nothing here closes your issue. If any of it is wrong or misses your point, reply on the thread and a person from the team will pick it up.