Add timeout and retry/backoff to PolarSelfClient outbound calls to api.polar.sh

[stilla]

PolarSelfClient (server/polar/integrations/polar/client.py) calls api.polar.sh (e.g. list_recurring_products -> GET /v1/products/) with no explicit httpx.Timeout and no retry/backoff. Any httpx.RequestError (e.g. ReadError, connection reset mid-read) is wrapped as PolarNetworkError -> PolarSelfClientOperationalError, which callers like organization.endpoints.list_plans do not catch, so it surfaces as a bare 500.

This isn't a one-off: Logfire shows the same ReadError -> PolarNetworkError chain hitting api.polar.sh at a baseline of 1-2/hr across both the api and worker services (also hit worker's get_order webhook processing the same day), plus a larger spike of 111 errors in one hour on 2026-07-20. Reference: Sentry SERVER-4WB.

Suggested fix

• Add an explicit httpx.Timeout and retry/backoff to PolarSelfClient's underlying httpx transport, following the pattern already used for the Tinybird client (Tinybird client: distinguish operational errors (network/server) from legitimate API errors #10652).
• Wrap list_plans()/list_recurring_products() calls in organization/endpoints.py to degrade gracefully instead of propagating a bare 500.

Related

• fix: treat 403 from self-client as operational error #11805 (closed, unmerged): prior attempt to broaden PolarSelfClientOperationalError classification (403 case)
• Tinybird client: distinguish operational errors (network/server) from legitimate API errors #10652: the analogous fix already applied to the Tinybird client

_{Sent by @maximevast from Stilla investigation.}

[VedantPatel04]

Hi, I would like to tackle this issue if it is open.

I wanted to mention a brief general overview of my plans:

1: pass a custom async_client with an httpx.Timeout

2. use retry_config to catch the ReadErrors.
3. Catch PolarSelfClientOperationalError --> return 503

Let me know if any adjustments should be made to logic. Will link the PR soon. :)

Thanks,
Vedant