Skip to content
This repository has been archived by the owner on Mar 9, 2018. It is now read-only.

Delivery Failures & Retries

Jump to bottom
Ian Leitch edited this page Nov 28, 2013 · 9 revisions

Rapns gracefully handles delivery failures, even when only a subset of registration IDs fail for a notification. Rapns also implements exponential back-off as defined in the GCM spec.

When all registration IDs for a notification fail with the state Unavailable or InternalServerError the entire notification is retried with exponential back-off. Registration IDs with the state NotRegistered are not retried.

When only a subset of registration IDs fail for a given notification, a new notification is created for the registration IDs that failed.

Examples of some error message you can expect to see as Rapns handles delivery failures:

  • Failed to deliver to all recipients. Errors: NotRegistered.
  • All recipients unavailable. Notification 1 will be retired after 2012-10-14 00:00:02 (retry 1).
  • Failed to deliver to recipients 0, 2. Errors: Unavailable, InternalServerError. 0, 2 will be retried as notification 2.
  • GCM responded with an Service Unavailable Error. Notification 1 will be retried after 2012-10-14 00:00:02 (retry 1).

Note: 'recipients 0, 2' in the examples above correspond to the index of the registration ID in the Rapns::Gcm::Notification#registration_ids array.

The reflection hook notification_will_retry is called for each retry. See Reflection API for more information.

For unhandled HTTP error codes, the notification will be marked as failed.

Clone this wiki locally