Currently, autopush considers a message to be "delivered" upon hand off to a bridge system. This was originally "ok" because those bridge systems provided very limited message tracking and analysis. We might want to consider switching to bi-directional message support in order to get device receipt message and error for improved tracking.
I'm not quite sure how we should reflect this back to the original subscription publisher, however, since many of those device receipts are async, and we have no way of notifying the publisher of the final state of any given push once they disconnect after delivery. Maintaining a long lived connection to the subscriber is not economically sustainable. This may be something that is only used internally and reported back as an internally recorded metric.
Currently, autopush considers a message to be "delivered" upon hand off to a bridge system. This was originally "ok" because those bridge systems provided very limited message tracking and analysis. We might want to consider switching to bi-directional message support in order to get device receipt message and error for improved tracking.
I'm not quite sure how we should reflect this back to the original subscription publisher, however, since many of those device receipts are async, and we have no way of notifying the publisher of the final state of any given push once they disconnect after delivery. Maintaining a long lived connection to the subscriber is not economically sustainable. This may be something that is only used internally and reported back as an internally recorded metric.