Client.build_request_session configures retries with:
# paddle_billing/Client.py:213
retries = Retry(total=self.retry_count, backoff_factor=1, status_forcelist=[429, 500, 502, 503, 504])
api.paddle.com is served through Cloudflare, which returns 520–524 for origin-side problems (522 = origin connection timeout). None of those are in status_forcelist, so they get zero retries even though they are exactly the transient class retries exist for — retry_count defaults to 3 but never applies.
Observed in production (SDK 1.15.0, Python 3.14) on a customer lookup:
Request failed: 522 Server Error: <none> for url: https://api.paddle.com/customers?email=...
The <none> reason phrase is itself a tell that the response came from Cloudflare rather than the Paddle application.
Expected: transient Cloudflare origin errors are retried with backoff like other transient failures.
Client.build_request_sessionconfigures retries with:api.paddle.comis served through Cloudflare, which returns 520–524 for origin-side problems (522 = origin connection timeout). None of those are instatus_forcelist, so they get zero retries even though they are exactly the transient class retries exist for —retry_countdefaults to 3 but never applies.Observed in production (SDK 1.15.0, Python 3.14) on a customer lookup:
The
<none>reason phrase is itself a tell that the response came from Cloudflare rather than the Paddle application.Expected: transient Cloudflare origin errors are retried with backoff like other transient failures.