Retries on push notifications
See original GitHub issuePushNotificationListener
could use its own notification queue to schedule retries.
See discussion at: https://groups.google.com/d/msgid/killbilling-users/CAJE4nfvdYty4SYyCfe1m94uoJWqaZwLGPCJwAAwCsB4Ht-o50A%40mail.gmail.com
Issue Analytics
- State:
- Created 9 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Amazon SNS message delivery retries - AWS Documentation
The delivery policy defines how Amazon SNS retries the delivery of messages when server-side errors occur (when the system that hosts the subscribed ......
Read more >Rretry mechanism of push notification to offline mobile phone
It's stored for only a limited period of time. The notification is delivered to the device when the device becomes available.
Read more >Mobile Push Message queuing, retry and expiry mechanism
Message store, forward and retry mechanisms. Automatic queuing of concurrent messages with message queuing capability; Messages not received will be stored ...
Read more >Push notifications - Kill Bill Documentation
Push notifications are a convenient way to get notified about events from the system. One can register a callback, i.e, a valid URL...
Read more >Apple Push Notifications - Resend on Failure? - Stack Overflow
My goal is to send a notification to 100 people and if 10 of them fail to be delivered, have those 10 failures...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think we should keep the logic as is: if the destination app is down (e.g. connect timeout), or unavailable (e.g. returns 500) or misconfigured (e.g. returns 301), we should assume the notification wasn’t received and we should retry later (i.e. send it again).
We should create a new queue, independent of the queue of the original event, responsible for these events. The queue would be similar to the one handling payment retries and do some sort of exponential delay retries over the span of, say, a few days (configurable).
I would also suggest we always insert in this new queue (effective date ==
now()
) and attempt to send in the notification queue callback, to avoid blocking the external bus (since the HTTP POST can take some time). @sbrossie thoughts?Does it make sense?
@pierre I created a PR https://github.com/killbill/killbill/pull/589 with this feature implemented.