InternalServerError Issue about pyfcm HOT 5 CLOSED

@olucurious I feel like the response object returned by the method notify_single_device() (for example) should be the actual requests library response object, and parse_responses() should be a utility method so that we can grab the header and status code to use appropriately. I may make these changes in my own local version.

This is a great library by the way, I'm really happy someone executed on this well.

from pyfcm.

@nirajkmr the issue has been fixed here: fdedcf6

@dwarrier Thanks for the suggestion, I'll find a way to expose that very soon, I'm just concerned about breaking changes and backward compatibility for so many people who are using the library in production.

from pyfcm.

@olucurious Thank You 👍

from pyfcm.

@olucurious Thanks for adding these changes! I guess one reason to expose the headers now would be if someone wanted to limit retries, which isn't a big deal as long as they're aware of the internals.

You've probably thought about this, but it seems like Retry-After header may contain a date instead of a time delta. I don't think it's worth handling a date response, but this may cause an unhandled exception from casting to an int: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.37. I would expect it to be a time delta most of the time, but Firebase documentation really doesn't help much here.

from pyfcm.

@dwarrier Yeah, I did spend some time thinking about that, I did some little research about the value in GCM(cos there isn't much information about FCM) and couldn't find any. I'll do more research and take care of it and also implement exponential back-off for multiple retries eventually.

from pyfcm.