Rpush gracefully handles delivery failures, even when only a subset of registration IDs fail for a notification. Rpush 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 Rpush 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 Rpush::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.