Notification Hub Namespace update failed with BadArgument Exception

[ChrWeinert]

We have a notification hub namespace that includes one notification hub. During the replacement of the Google fcm message support we wanted to set the new FCM v1 settings through our bicep script. Because these settings are only available in the "2023-10-01-preview" version, we updates our script to this version.

When running the deployment we get the following error

{
  "status": "Failed",
  "error": {
    "code": "BadArgument",
    "message": "Value cannot be null. (Parameter 'value')",
    "target": "value"
  }
}

Because we can´t get more detail information about this error, we made some tests within an empty resource group. We created a new notification hub namespace with a notification hub and the FCM v1 setttings. Everything works fine.

When we re-run the bicep we always get the same error.

When we delete the notification hub namespace and re-run the script, everythings is working again.

It seems, there might be an issue when the deployment tries to update an existing notification hub namespace. We tried this with the API Version "2023-09-01", but the error also happens here.

Maybe someone can help us to figure out what is going wrong and how we can update our existing notification hub (namespaces) without getting this error.

Best Regards Christian

Here is the bicep script we use to reproduce the issue:

resource notificationHubNamespace 'Microsoft.NotificationHubs/namespaces@2023-10-01-preview' = {
  name: 'ntfns-mynotificationhubnamespace'
  location: resourceGroup().location
  sku: {
    name: 'Free'
  }
  properties: {
    namespaceType: 'NotificationHub'    
  }

  resource RootManageSharedAccessKeyAuthorizationRule 'AuthorizationRules' = {
    name: 'RootManageSharedAccessKey'
    properties: {
      rights: [
        'Listen'
        'Manage'
        'Send'
      ]
    }
  }

  resource notificationHub 'notificationHubs@2023-10-01-preview' = {
    name: 'ntf-myNotificationHub'
    location: resourceGroup().location

    resource DefaultFullSharedAccessSignatureAuthorizationRule 'AuthorizationRules' = {
      name: 'DefaultFullSharedAccessSignature'
      properties: {
        rights: [
          'Listen'
          'Manage'
          'Send'
        ]
      }
    }

    resource DefaultListenSharedAccessSignatureAuthorizationRule 'AuthorizationRules' = {
      name: 'DefaultListenSharedAccessSignature'
      properties: {
        rights: [
          'Listen'
        ]
      }
    }

    resource DefaultManageSendListenSharedAccessSignatureAuthorizationRule 'AuthorizationRules' = {
      name: 'DefaultManageSendListenSharedAccessSignature'
      properties: {
        rights: [
          'Listen'
          'Manage'
          'Send'
        ]
      }
    }

    resource DefaultSendListenSharedAccessSignatureAuthorizationRule 'AuthorizationRules' = {
      name: 'DefaultSendListenSharedAccessSignature'
      properties: {
        rights: [
          'Listen'
          'Send'
        ]
      }
    }

    resource DefaultSendSharedAccessSignatureAuthorizationRule 'AuthorizationRules' = {
      name: 'DefaultSendSharedAccessSignature'
      properties: {
        rights: [
          'Send'
        ]
      }
    }
  }
}

--- Origin Post --- https://github.com/Azure/bicep-types-az/issues/2222

[MrBear141]

Any updates on this one? The bug is pretty critical, we can not add NotificationHub as part of our IaC flow.

[dtap001]

Any update on this?

[dtap001]

@MrBear141 did you solved it?

[Abhi-532]

any update on this ?

[dtap001]

@Abhi-532 shamefully the only solution is to export all of the device registration from your hub, delete it then deploy again and import the device registrations. I will never use any ms azure solution again...

[MrBear141]

the issue is very critical, IaC flow can not work properly. Can anyone from azure team give some info about the bug? If it is not gonna be fixed, we are gonna move to some other notification solution. Any info would be appreciated.