Open mimikadze opened 11 years ago
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?
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.
Any updates on this?
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.