I am trying to store failed notifications in a db, e.g. client does not have internet access. This will enable me to check from a backgroundService if there is a missing notification, and then create it from the backgroundService.

I therefore have the following, on my Azure App Service Mobile:

var notStat = await hub.SendWindowsNativeNotificationAsync(wnsToast, tag);
telemetry.TrackTrace("failure : " + notStat.Failure + " | Results : " + notStat.Results + " | State : " + notStat.State + " | Success : " + notStat.Success + " | trackingID : " + notStat.TrackingId + ");

The code snippet was to test the impact from the client, but no matter what I do the resulting log is just that the message was enqueued.

Question

So how to I detect failed Notifications?

Conclusion

To sum up the discussions made to the accepted answer:

When the notification has been send, the NotificationId and other relevant data, is stored in a separate Table.

The event on the client receiving the notification, will then send a message to the server stating that the notification is received. The entry is then removed from the Table.

The notifications that then are not received by the client, will through a background task be found. This will be every time the background task fires, e.g. every 6 hours, the background task will retrieve all the missing notifications. This enables the background task to create the relevant notifications and the user will not miss any notification.

The return of enqueued is expected - please, refer to the troubleshooting guidance. For more insights on what is happened try to set the EnableTestSend -

"result.State will simply state Enqueued at the end of the execution without any insight into what happened to your push. Now you can use the EnableTestSend boolean" (c) documentation

But be aware that when EnableTestSend is enabled, there are some limits (described on the same page, so will not copy paste it here to avoid the future issues with the outdated info).

You can use Per Message Telemetry functionality or REST API as well - Fiddler+some documentation.

And, as a follow-up questions, there were some discussions on SO i saw that you may find helpful: first and second.

And, as a last one, i would highly recommend (if you did not yet) to take a look at FAQ - it is important to know how different platforms handle the notifications, to avoid the situation when you try to debug something that was done by desing (for example, maybe, if the device is offline, and there are notifications, only the last will be delivered, etc).