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

Rapns::DeliveryError, Unable to deliver notification #, received error 8 (Invalid token) #159

Open
mimikadze opened this issue Sep 4, 2013 · 3 comments

Comments

@mimikadze
Copy link

We met the problem of delivery failures after message with invalid token was sent in the queue with valid ones. I mean not only that message fails, but the rest of messages with valid tokens. We could reproduce the issue working with our backend through TestFlight profiles instead of production profile of an app.

I've generated example logfile here http://pastebin.com/6B48raf8

As u see, we've got one invalid token message, but we don't recieve even next message, nevertheless nor error were received from APNS server.

We suppose we met an issue described in this post http://redth.info/the-problem-with-apples-push-notification-ser/ when Apple closes session after our damaged or expired device token, but rapns gem tries to send other enqueued messages the same way.

Hope, you'll find some workaround.

@ileitch
Copy link
Owner

ileitch commented Sep 4, 2013

Yes, I'm planning to implement the solution that PushSharp uses.

The log indicates that the error was detected and the connection re-established, I'd expect you to receive the following notifications in this scenario. By default rapns uses the waiting strategy described in that blog post, I'd only expect for notifications to go silently undelivered if the check_for_errors config option were disabled.

Does the problem persist for many notifications, or only the one immediately after the failure?

@mimikadze
Copy link
Author

You can guess that it's difficult to reproduce this issue due to many devices should be involved and so on. But we found out empirical that crash of a single token involve random token crashes after it's occur, not only the next one. We could provide you more debug information or reproduce some cases on demand.

Do you have some roadmap for this feature? I suppose it's not correct of me to make a pull request with such a feature cause it lead to heavy core changes of the gem architecture. Can I implement some temporary solution using check_for_errors option? I dont't see how for now, but nevertheless.

@tritter
Copy link

tritter commented May 18, 2015

Any updates on this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants