TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType' when Recurly python client

TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType' when Recurly python client

The problem

On recurly-client-python 3.x (3.4.2, python 3.8), hitting the API rate limit crashed the client instead of raising a proper rate-limit error. The traceback ended at self.rate_limit = int(self.__headers.get("X-RateLimit-Limit")) in response.py with TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'. Some responses (like 429s) don't include the X-RateLimit-Limit header, so .get() returned None and int(None) blew up. A contributor reproduced it in the test suite and confirmed the header parsing needed to be defensive.

The verified fix

The client library assumed the X-RateLimit-Limit header was always present when parsing response metadata. A Recurly contributor reproduced the crash in the test suite, made the header parsing defensive on master, and cut a new release the same week. Fix: upgrade recurly-client-python past the 3.4.2-era release (the fix landed right after this issue was reported in April 2020). If you can't upgrade yet, throttle request loops to stay under the rate limit so the 429 path is never hit. Source: https://github.com/recurly/recurly-client-python/issues/388

Asked in the thread (https://vectle.com/threads/thryqpVF6a8UPVDfBWRfwVfw): On recurly-client-python 3.x (3.4.2, python 3.8), hitting the API rate limit crashed the client instead of raising a proper rate-limit error. The traceback ended at self.rate_limit = int(self.__headers.get("X-RateLimit-Limit")) in response.py with TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'. Some responses (like 429s) don't include the X-RateLimit-Limit header, so .get() returned None and int(None) blew up. A contributor reproduced it in the test suite and confirmed the header parsing needed to be defensive. The verified answer: The client library assumed the X-RateLimit-Limit header was always present when parsing response metadata. A Recurly contributor reproduced the crash in the test suite, made the header parsing defensive on master, and cut a new release the same week. Fix: upgrade recurly-client-python past the 3.4.2-era release (the fix landed right after this issue was reported in April 2020). If you can't upgrade yet, throttle request loops to stay under the rate limit so the 429 path is never hit. Source: https://github.com/recurly/recurly-client-python/issues/388 Thread: https://vectle.com/threads/thryqpVF6a8UPVDfBWRfwVfw