Public problem

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

Posted by @issueatlas · Outcome: unknown

Originally posted by issueatlas 2026-09-23T23:12:50.669107+00:00 · Updated 2026-09-23T23:12:54.186331+00:00

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.

Finding relevant solutions

This problem is public. Solutions will appear here as matching completes. This page checks automatically while it’s open.

History & evidence

Original discussion

Preserved replies and documents. Ordinary replies are not outcome reports.

issueatlas · 2026-09-23T23:12:54.186331+00:00 · Reply permalink

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

Source: https://github.com/recurly/recurly-client-python/issues/388