I am currently having an issue with a webhook that uses multiple threads.
The webhook updates a status column on a Notification table.
The first webhook should come and update a notification to sent and then the second webhook updates the same notification to delivered. However on occasion the webhooks are coming through exactly the same time due to multiple threads, and updating in the wrong order (updating to delivered first, and then sent).
I originally attempted a fix by saying 'only update the status column if the status is not delivered', but this doesnt seem to work (i imagine because of threads)
I've looked into it more and i think i need to use with_lock on the notification instance. However my question is, when using with_lock when updating to sent, will the delivered webhook wait until the table is free again so it can update it to delivered, or does it just give up, and ignore the delivered update entirely, therefore meaning the status will forever be stuck in sent?
(Or any other suggestions welcome)
Related
The Apple docs talk about notification webhooks retrying messages if they fail. However, this adds the complexity of trying to figure out the order of events as they may reach your server in the wrong sequence.
Surprisingly, the only timestamp I can find on a notification is the signedDate. Should/can this be used to order the notifications? I'm making the assumption that when a notification is retried (up to 72hrs later) that the message isn't re-signed, but there's no documentation saying whether or not this assumption is true.
Is there some other way to do this?
I have application who is getting notifications from Outlook, it is subscribed for update,create changes in users mailboxes. I am getting notifications all day long even if the users are not active (It is their sleep time). Can I know how notifications are sent to me?
There are all sorts of background tasks (assistants), both time based and event based that wake up and do work on the system. In addition, there may be apps that the user has given permissions to operate on their mailbox that may be doing something behind the scenes. Exchange doesn't differentiate. When a change is made that matches the criteria in the subscription, a notification will be generated.
I have set up a microsoft graph webhook to monitor changes in messages, with my application, that was working great in production.
What is happening is the webhook is not sending notifications as quickly as I would expect it to send its notifications. Sometimes it is immediate, sometimes it takes an hour, I do not understand why this is happening.
Any help would be much appreciated.
Webhooks subscriptions expire after a certain time and/or if your webhook crashes often or takes too long to reply on regular basis.
You need to renew your subscription on regular basis in order to keep it going.
You can find more information about that here https://www.eliostruyf.com/creating-and-renewing-your-microsoft-graph-webhook-subscriptions/
I don't think you should be expecting any guaranties that the notification will be instantaneous (or almost). The reason is all that works with a message queue pattern and a reduce pattern behind the scenes. Notifications are async, and can be delayed depending on the service, on the number of notifications to go to the same subscriber and so on
I'm using Plot Projects for iOS.
When I have finished filtering notifications through the PlotFilterNotifications method, I use filterNotifications.ShowNotifications to send these notifications to iOS.
The problem is, this doesn't seem to add them to the notification centre in the usual way, as when I check the UIApplication.SharedApplication.ScheduledLocalNotifications call, I get back an empty array. Also none of the usual methods work for removing this from the notification, such as UIApplication.SharedApplication.CancelAllLocalNotifications or setting the badge count to 0.
I have tried scheduling the notifications manually by taking the notification from the PlotFilterNotifications method and bypassing the filterNotifications.ShowNotifications method, and cancelling this notification when the user receives an exit notification for the site if the scheduled time has not yet passed, but if a user passes through a site too quickly the notification doesn't get cancelled so I do need to use the built in functionality.
You call the method filterNotifications.ShowNotifications with all passed notifications in the list, and then try to cancel/clear them straight after that? It is then possible that you try to cancel them before they are sent, since they aren't sent instantly when that method is called. That work is done on a different thread, since it involves some I/O operations.
You could alter the notifications passed to the notification filter to a single notification. Then only that single notification is sent. You change the message and other properties of the notification. A disadvantage would be though that the other notifications aren't considered sent in the statistics.
I have an iOS app integrated with Parse.com in which I want to schedule push notifications for certain dates/times. I am storing a push notification time on PFInstallation objects for users who have an upcoming event. I have a scheduled job running on Parse CloudCode that queries for push notification times that need to be sent within the next minute. Is this a good way to architect this? If so, how can I send this push? Parse.Push takes a query for it's where field, but queries only return up to 1000 results which doesn't scale at all for a free app. Thus, I'm trying to use Parse.query.each() which has an unlimited number of results. However, now I'm unsure how to send a push to each installation this way? Do I need to create another query within my each() statement? That seems redundant and inefficient.
(Note that the push notification is a silent notification with the content-available flag set so local notifications are not an option. Also the notifications can be cancelled by the user so scheduling the notification with the CloudCode push schedule API is not an option since those pushes can't be cancelled.)
You say, you store push notifications time on the respective PFInstallation object to circumvent the lack of support for canceling a push notification through Parse, great. We'll call that column ScheduledPushDate; That's the easy part; +1. The part you want to accomplish is actually scheduling a push notification using the given date. Great. Another easy part; +1. The hard part is doing it the way you want; -2. Parse.Push is not only limited by the where field. A lot of variables come into play when sending a push, for example, Parse doesn't even consider any objects that don't have a valid deviceToken so you can omit those objects immediately. The problem your running into is not the push itself, its not how to query for validation, its simply comes down to canceling it. Sure you can always change the date in ScheduledPushDate to be something in the year 2025 or simply negating it altogether, but that doesn't matter because you've already given the notification a scheduled date with the payload. Keeping it simple, and according to your target (you tagged iOS, so this is an answer specifically to client-side resources since you don't want to use local notifications or cloud code) you won't be able to cancel it, because within the guidelines given, you can only construct a push notification so many ways with Parse (client-side, cloud code, dashboard), and as of right now, only one of those options allows a successful means to cancel the process, and it's through the dashboard/console.
Lets say you do it the way you are thinking about:
Execute scheduled job to search for push times that need be fired within the coming minute. What is a "coming minute". Lets say a users time is 11:35.46 (11am35m46sec) and they want to cancel the scheduled notification and cancelled it at that moment, but your job fired at 11:35.00? Realistically, how often will that happen, not many, but it will happen and can happen. You should always code for every circumstance a user will encounter, not just the ones you want to prevent.
Additionally, you would be exhausting almost all of your API request limits if you do have a scaleable app as mentioned.
Lastly, to answer your question, no you don't have to do an innerQuery or additional query within the query.each function, as it's job is to iterate over each result of a query