How to know if trigger event failed?
I have a test app where I created test-template, which has 2 steps, push and in-app. If the push step fails, the trigger event will stop, and right now I am sending the notification to a user that has no push subscription configured, and the template fails succesfully. However, the response I get is the same as if the notifcation was sent correctly. It has no errors, it is acknowledged and with status processed. So, using the API, is there no way to get a failure response when the transaction actually fails?
In the pasted image you can see the trigger event done to the user with subscriber_id 100, and a response which indicates success, but in the dashboard the trigger event is marked as failed.
5 Replies
Let me give some details on why I need to be able to know which transactions were succesful and which ones weren't.
I want to implement a retry system to guarantee eventual consistency among OneSignal, Novu and my database, and I was planning on having a notifications table with the transaction IDs generated by Novu and then, for every failed transaction, send it again by means of a background worker.
I just found out about the
getNotifications endpoint, but that one gives you all the notifications and you have to check which ones are pending, and with increasing number of notifications, it would take too long. Another thing I thought of was to use the getNotification endpoint, but that one takes in a notificationId, not the transactionId, and I don't know where to get that id from.
So, can you point me towards the right direction on how to achieve this, which endpoint would be appropriate?Hey @Bocorbojon 🙂 Great question and a very interesting use case! If you can help understand between two specific cases, a provider is failing and we need to move to another one, and manage the full workflow of a notification for a single subscriber.
If we are talking about the first one, I'd love to hop on a call and learn what are you thinking to do there 🙂 If it's the second one, I'll ask @dimagrossman or @Pawan Jain to give us some more info here.
Hi @Bocorbojon, you could use the https://docs.novu.co/api/get-notifications/ endpoint and provide the "TransactionId" as a filter.
Another question regarding you need, will managing a retry policy on our behalf automatically (for example, if one singal fails, we can do a backoff retry mechanism to make it again) will solve your need? Or you will still have to manually handle it
Get notifications - Novu API Reference
Novu is an open-source notification infrastructure built for the engineering teams to help them build rich product notification experiences without constantly re-inventing the wheel.
Let me explain again to see if it's clearer. Let's suppose I am using Novu with the OneSignal integration, and I have a template with two steps: push and in-app, in that order. I configured the template so that, if the push step fails, the whole transaction fails. I want it to work that way so, in case of whatever error on the side of OneSignal, the in-app notification is cancelled.
So, ideally, when I do the OneSignal.trigger, I would want to know if the transaction was completed successfully. Though, I guess that couldn't be done because of the case that the user has the app closed, right? Your backend delays the actual sending of the notification and the "acknowledged" response is like saying "I received your notification request, but I haven't necessarily sent it yet". Tell me if I am undertanding it correctly.
The other alternative is checking the actual notification through the API endpoint to actually know if it was sent correctly or not. If it wasn't, I would retry the trigger event in my backend, with a script working on another thread, and keep retrying until both OneSignal and Novu sent the notification correctly to the user.
You implementing a retry system on you backend would indeed be a better solution, probably more robust, since you already have support for things like delaying notifications. Also, thinking about it quickly and superficially, right now I don't know if I would need to design some special approach with the broadcast-type notifications, nor if I will have any complications with them .
Another thing, how can I use the transactionId as a filter?
send transactionId value in query param of
/notifications endpoint
/notifications?transactionId="YOUR_TRANSACTION_ID"