azure-sdk-for-net icon indicating copy to clipboard operation
azure-sdk-for-net copied to clipboard

[BUG] NotificationHubResource 'DebugSend' throws an exception with a successful notification when the status in not 201

Open kenziereed opened this issue 2 years ago • 2 comments

Library name and version

Azure.ResourceManager.NotificationHubs 1.0.0

Describe the bug

When calling the DebugSend/DebugSendAsync on the NotificationHubResource, an exception is thrown. However, the contents of the exception indicate that the push was successful. Additionally, the exception includes which push notifications were successfully sent (gcm, apple, etc).

Service request failed.\r\nStatus: 200 (OK)\r\n\r\nContent:\r\n{\"properties\":{\"success\":10,\"failure\":0,\"results\":[{\"applicationPlatform\":\"gcm\",\"outcome\":\"The Notification was successfully sent to the Push Notification System\"},

There is an optional parameter for the DebugSend/DebugSendAsync that supplies content to the request. Regardless of whether it is supplied, a 200 is returned.

image

In NotificationHubsRestOperations, the DebugSend that is called by the NotificationHubResource throws an exception for any status other than 201:

image

Expected behavior

NotificationHubRestOperations would not throw an exception for a 200 if the push notifications are successful or depending on the expected results of the Azure Management API, NotificationHubResource would not allow an optional parameter if an error would be thrown regardless.

The SDK expects a 201, which makes sense for a POST. So, I initially assumed it was related to a serialization issue of content that was passed to the API, but in that case, I would also expect the API to return a status code other than 200.

Actual behavior

Without the message supplied to NotificationHubResource DebugSend and with a message supplied that was successfully used in the Azure Portal for testing, an error is thrown with a 200 status with the number of successful devices is supplied.

Reproduction Steps

Here is a small test snippet without the message passed:

var client = new ArmClient(new DefaultAzureCredential()); var subscription = await client.GetDefaultSubscriptionAsync(token); var resourceGroups = subscription.GetResourceGroups(); var resourceGroup = await resourceGroups.GetAsync(this.resourceGroupName, token); var notificationNamespace = await resourceGroup.Value.GetNotificationHubNamespaceAsync(this.notificationHubNamespace,token); var hubResource = await notificationNamespace.Value.GetNotificationHubAsync(this.notificationHubName, token); var result = hubResource.Value.DebugSendAsync(cancellationToken: token);

Environment

.NET 6.0 Visual Studio Version 17.0.12

kenziereed avatar Sep 21 '22 13:09 kenziereed

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'ARM:0.36921346,Service Bus:0.11641518,KeyVault:0.100513384'

azure-sdk avatar Sep 21 '22 13:09 azure-sdk

Thank you for your feedback. Tagging and routing to the team member best able to assist.

jsquire avatar Sep 21 '22 13:09 jsquire

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @tjsomasundaram.

Issue Details

Library name and version

Azure.ResourceManager.NotificationHubs 1.0.0

Describe the bug

When calling the DebugSend/DebugSendAsync on the NotificationHubResource, an exception is thrown. However, the contents of the exception indicate that the push was successful. Additionally, the exception includes which push notifications were successfully sent (gcm, apple, etc).

Service request failed.\r\nStatus: 200 (OK)\r\n\r\nContent:\r\n{\"properties\":{\"success\":10,\"failure\":0,\"results\":[{\"applicationPlatform\":\"gcm\",\"outcome\":\"The Notification was successfully sent to the Push Notification System\"},

There is an optional parameter for the DebugSend/DebugSendAsync that supplies content to the request. Regardless of whether it is supplied, a 200 is returned.

image

In NotificationHubsRestOperations, the DebugSend that is called by the NotificationHubResource throws an exception for any status other than 201:

image

Expected behavior

NotificationHubRestOperations would not throw an exception for a 200 if the push notifications are successful or depending on the expected results of the Azure Management API, NotificationHubResource would not allow an optional parameter if an error would be thrown regardless.

The SDK expects a 201, which makes sense for a POST. So, I initially assumed it was related to a serialization issue of content that was passed to the API, but in that case, I would also expect the API to return a status code other than 200.

Actual behavior

Without the message supplied to NotificationHubResource DebugSend and with a message supplied that was successfully used in the Azure Portal for testing, an error is thrown with a 200 status with the number of successful devices is supplied.

Reproduction Steps

Here is a small test snippet without the message passed:

var client = new ArmClient(new DefaultAzureCredential()); var subscription = await client.GetDefaultSubscriptionAsync(token); var resourceGroups = subscription.GetResourceGroups(); var resourceGroup = await resourceGroups.GetAsync(this.resourceGroupName, token); var notificationNamespace = await resourceGroup.Value.GetNotificationHubNamespaceAsync(this.notificationHubNamespace,token); var hubResource = await notificationNamespace.Value.GetNotificationHubAsync(this.notificationHubName, token); var result = hubResource.Value.DebugSendAsync(cancellationToken: token);

Environment

.NET 6.0 Visual Studio Version 17.0.12

Author: ghost
Assignees: xboxeer
Labels:

Notification Hub, Service Attention, Mgmt, customer-reported, question, needs-team-attention

Milestone: -

ghost avatar Feb 08 '23 14:02 ghost

Since this issue is related to the service side and not the SDK side, so we are not able to help you with it. Therefore, we are closing this issue for now. If you need more assistance, please open an Azure support request. We apologize for any inconvenience this may cause you.

We value your feedback and we want to make sure that your problem is solved. If you think that we have misunderstood your issue or closed it incorrectly, please feel free to comment on this thread and reopen the issue. We will be happy to assist you further. Thank you for your understanding and cooperation.

ArthurMa1978 avatar Aug 15 '23 04:08 ArthurMa1978