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.

[jatin-sisodia]

Hi this is a confirmation from Azure team that we have a known Bug in Bicep Script for update operation @2023-10-01-preview'.
We are working on the fix.
If possible, it is recommended to use management apis until that bug is fixed
https://learn.microsoft.com/en-us/rest/api/notificationhubs/operation-groups?view=rest-notificationhubs-2023-09-01

Hope this helps!
Thanks

[bvegso]

i was recommended to revert the apiVersion for the namespace to 2017-04-01 and keep the rest at 2023-10-01-preview. it seems to re-deploy fine like that

 "resources": [
     {
       "type": "Microsoft.NotificationHubs/namespaces",
-      "apiVersion": "2023-10-01-preview",
+      "apiVersion": "2017-04-01",

while:

    {
      "type": "Microsoft.NotificationHubs/namespaces/notificationHubs",
      "apiVersion": "2023-10-01-preview",

etc.

[jatin-sisodia]

Hi @bvegso, Yes we can use older version i.e. 2017-04-01 but for usecases specifically to FcmV1, 2017-04-01 version does not support them. For all other use cases we can keep on continuing the older version as a workaround until the bug is fixed.

Thanks !

[bvegso]

the Microsoft.NotificationHubs/namespaces resource needs to be deployed with 2017-04-01 but everything else, including the Microsoft.NotificationHubs/namespaces/notificationHubs, which contains the FCMv1 credentials, can be deployed with 2023-10-01-preview. we have tested this and seemed to deploy fine
having said this, we are working with ARM templates, not sure if this is possible in Bicep

[eth-ellis]

Hi @jatin-sisodia, any update on how the fix is going?

[dtap001]

@eth-ellis: use bvegso's solution. It will work.