Been working with subscriptions for the past few months and haven't had issues. Today our service has been down because changes made for Contacts and Events are not issuing a notification to our API. I have resubscribed several times in different environments to no avail. Code base has not changed for the past couple days.
The URL for the POST is: https://graph.microsoft.com/beta/subscriptions
This is the request payload (2018-12-13T14:40:48.321209 PST):
{
:changeType=>"created,updated", :notificationUrl=>"https://da532483.ngrok.io/office365/subscription/notification", :resource=>"/me/calendars/AQMkADAwATY3ZmYAZS1lZmRkAC1lOTZhLTAwAi0wMAoARgAAA6PhSGdMGt9Nkwdvvtt9NrIHAD-_YGH8PpRIvfFpb45sC10AAAIBBgAAAD-_YGH8PpRIvfFpb45sC10AAtZPfToAAAA=/events",
:expirationDateTime=>"2018-12-16T21:10:48+00:00",
:clientState=>"clientState"
}
And the response payload (2018-12-13T14:40:49.339139 PST):
{
"#odata.context":"https://graph.microsoft.com/beta/$metadata#subscriptions/$entity",
"id":"d07de8ab-2c6c-447c-90d1-2b583318c597",
"resource":"/me/calendars/AQMkADAwATY3ZmYAZS1lZmRkAC1lOTZhLTAwAi0wMAoARgAAA6PhSGdMGt9Nkwdvvtt9NrIHAD-_YGH8PpRIvfFpb45sC10AAAIBBgAAAD-_YGH8PpRIvfFpb45sC10AAtZPfToAAAA=/events",
"applicationId":"0e8eebe4-55dc-4bd6-91ac-c13f91bb145d",
"changeType":"created,updated",
"clientState":"clientState",
"notificationUrl":"https://da532483.ngrok.io/office365/subscription/notification",
"expirationDateTime":"2018-12-16T21:10:48Z",
"creatorId":"00067FFEEFDDE96A"
}
Any help would be greatly appreciated.
Sorry about the issues you experienced with Microsoft Graph webhook notifications.
Here is what happened:
We experienced a capacity issue that resulted in a delayed deliveries for a subset of notifications. Some subscriptions were affected more than others, with some subscribers seeing a significant drop in notifications delivered. The time period for this issue was between 2AM on 12-12-2018 and 6PM 12-13-2018 (PST).
What we are going to do:
1.We are investigating the root cause and will take steps to prevent this from occurring in the future.
2.We recognize that our outage communications for Graph notifications are lacking. We are working on improving our comms with the goal of pro-actively publishing service degradation info to our customers as soon as we realize they occur.
We appreciate your usage of Graph and our webhook notification framework. Sorry about the trouble!
Related
I have a cloud run service deployed, with an eventarc trigger which creates a pubsub topic behind the scenes, to which the trigger is subscribed.
Recently to my horror I noticed the trigger was not being invoked anymore. Looking further I noticed there were 0 subscriptions to the pubsub topic. I went to the cloud run service console and the trigger still existed, so why no subscription to the topic?
I have redeployed the service multiple times before, and the subscription has never disappeared like this. Deleting and re-creating the trigger brought back the subscription, however now I lost all my messages. :-(
Can anyone explain how this could happen, and if it does happen again, how I can re-enable the subscription without re-creating the trigger and thus losing all my pubsub messages?
Thank you very much.
Pub/Sub subscriptions created by Eventarc triggers should definitely not expire. If you see this again, please open a bug with details: https://cloud.google.com/support/docs/issue-trackers
I received this message from the engineering team:
"As of May 3rd, pubsub subscriptions created by creating an Eventarc trigger are set to never expire. Previously, they had a default expiration of 30 days of inactivity.
It sounds like what the customer is experiencing is consistent with that. What happened was there were 30 days of inactivity and the subscription expired.
The workaround at the moment would be to create a new trigger."
Based on my understanding of how subcriptions work, it seems like we should build some sort of cron job to check if almost about to expire users were renewed since notifications won't be sent in some cases.
Based on reading these:
https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_
https://medium.com/revenuecat-blog/ios-subscriptions-are-hard-d9b29c74e96f
my question is:
is my conclusion true? are notifications not sent for renewals?
if I have to build a cron job and call verifyReceipt myself I can imagine that I would call it quite a lot per day, is there a limit to how many times I can call this endpoint? When will I be throttled?
Notifications are not sent for regular renewals. You will get a notification (INTERACTIVE_RENEWAL) if the user cancels and resubscribes. Best practice would be to check the /verifyReciept endpoint to get subscription status from Apple. There aren't any published throttles on this endpoint and would imagine it's extremely scalable.
Also, highly recommend RevenueCat to completely manage subscription status for you.
I'm using the Wink API to control lights and thermostats etc. In the API you can subscribe to device topics to receive events such as when a light is turned on or off. This is handled through PubNub. I have this all working except that the events stop being sent if I leave the system overnight.
If I try to "manually" toggle a light by tapping the physical switch then normally an event is fired and received by my application via PubNub. Restarting my application and thus reconnecting to PubNub does NOT resolve the issue. The only way I've found to resolve the issue is to open the Wink app itself. Nothing else needs to be done but to open the Wink app. Then if I manually toggle the switch the event will show up and be received by my application. This solution works even if I don't restart my application.
There appears to be some sort of wake or keep-alive going on. Although I don't see anything in the Wink API docs that state such. There is also nothing sent from PubNub during this downtime. I have logging being sent out for the status(), message(), and presence() callbacks and nothing is logged from these overnight. Therefore taking all the above into account I believe the issue resides on the Wink side of things.
Unfortunately, Wink does not provide developer support. The Wink app is obviously doing something but because the transactions are encrypted it is unknown what it is doing. Also my test cycle is 8 hours long currently so it is difficult to debug this by trial and error. I'm working to see if this "timeout" is shorter than the overnight 8 hours I've experienced so far. i've also tried power cycling my Wink Hub yesterday but that did not resolve the issue.
Anyone else run into this issue? How do you keep subscriptions alive so that they are always sent?
I'm trying to decide which way to implement a "quiet hours" feature in my app to allow users to specify times in which push notifications should be silent. I see two options:
1) Server-side. Their settings are sent to the server which sends notifications with different properties (or perhaps not at all) during quiet hours.
2) Client-side. The app receives all notifications via silent push, the app then processes each notification and only notifies the user as appropriate.
I see problems / limitations with each method.
For #1, the implementation becomes more complex (especially if I want to add additional notification filters based on alert type, etc), and the issue of which timezone the client is in would be very hard to resolve (especially as the client moves from one timezone to another). I certainly don't want to be tracking their position and updating their current timezone on the server.
For #2 I have read a number of comments in various places that the silent push that goes only to the app is not as reliable as normal push notifications that directly notify the user and are not processed through the app. I would prefer to implement quiet hours in this way, but I am very concerned about a reduction in the reliability of the notifications coming through. I have also read that the app will NOT be started in the background if the user has force-quit it. Is that still the case?
I have two questions. First, how have others handled this concept of quiet hours? Second, is the silent push as unreliable as I have heard in the real-world, or has this gotten better (or worse) with the latest versions of iOS? I know there are factors, such as how much power the app consumes while processing these notifications. On average my app would only receive a few silent notifications a day, and processing would be very fast.
Not sure this is really an answer, but too much for a comment!
Is your app likely to be used in different time zones?
Or are your users all based in one country?
This could mean handling client side is going to be a lot simpler.
Also remember that there is no guaranteed delivery time of a push, its normally pretty instant, but not always, so although you might of sent it with 5 minutes to spare before a quiet hour, it might arrive after the quiet hour has actually started.
I am quite new into programming and I cant find efficient solution for my problem. Could someone point me in the right direction please?
I have an app which is heavily relying on server data. Data on server is unique for each user and may change every minute as well as only every few hours. Currently I am updating local data when app becomes active but I also need a way of notifying app to trigger updates when app stays in active state and data has changed on server. I thought about few solutions:
1) NSTimer set to one minute and triggering url request to check if there is new data on server. Server after comparing lastModified value would return new data if available.
I don't really like that solution as I don't want to overload my server with number of requests, especially that data in the database may change only every few hours or even longer.
2) APNS - sending notifications from server every time data will change and than update local data with server database when notification received.
It seems like a good solution but only if it would be possible to restrict remote notifications to be received when app is in active state. As far I know it is not possible and as I mentioned before data may change even every minute so I don't want to spam users with number of notifications when app is not running.
3) TCP Sockets using NSStream/CFStream?
This is something I never did before, so I am not even sure if I am going in the right direction researching about this one.
This is a hard topic in general, but more technologies are coming out to help with it. Couple thoughts on each of your solutions:
The NSTimer solution is effectively polling, which is the worst option I feel. You'd be hitting your server pretty hard for each user.
This would be a better solution. APNS now supports silent notifications, so you can send push notifications to a user without worrying about notifying them. You can send a silent notification by including the content-available key in the payload and not including the alert key. More info here: http://hayageek.com/ios-silent-push-notifications/. It is rate limited, though. You may go minutes to hours without getting a delivery, so if that's important you'd be best to go to option 3.
This is your best solution. It would require a persistent connection with your server. AFNetworking 2.0 supports this kind of connection based on Rocket. Here's Rocket's documentation: http://rocket.github.io. Take a look at server-sent events.
Hope that helps!