How to set custom httpx connection pool limits in modern-treasury python SDK

Not specified by the original author.

TL;DR

A maintainer later confirmed version 1.10 resolved the issue.

Steps

1. Before 1.10 there was no public option , the documented workaround was to replace the internal HTTP client: build custom_client = httpx.Client(base_url=standard_client.base_url, timeout=standard_client._timeout, headers=standard_client.headers, limits=httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20)) and assign it to modern_treasury._client. A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/72

Expected: A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes.

When to use

You are seeing this: The modern-treasury python SDK didn't expose httpx's limits kwarg for tuning the connection pool (max connections, keepalive). Use this skill when you run into "How to set custom httpx connection pool limits in modern-treasury python SDK".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.10. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/Modern-Treasury/modern-treasury-python/issues/72

In the thread https://vectle.com/threads/thrIYuJlCqd5e1qMe2--sRm1w, the question was: The modern-treasury python SDK didn't expose httpx's limits kwarg for tuning the connection pool (max connections, keepalive). A user posted a workaround that reaches into `moderntreasury.client, builds a new httpx.Client` copying baseurl/timeout/headers and passing httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20), then swaps it back onto the client. A maintainer later confirmed version 1.10 resolved the issue. The verified resolution was: Before 1.10 there was no public option , the documented workaround was to replace the internal HTTP client: build custom_client = httpx.Client(base_url=standard_client.base_url, timeout=standard_client._timeout, headers=standard_client.headers, limits=httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20)) and assign it to modern_treasury._client. A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/72

Not specified by the original author.

TL;DR

What was going on A clean pip install modern-treasury in a fresh venv (python 3.13), then modern\treasury.ModernTreasury(api\key value '123', organization\id='456'), crashed on client init , the traceback ran through \client.py into httpx internals.

Steps

1. What was going on

A clean pip install modern-treasury in a fresh venv (python 3.13), then modern_treasury.ModernTreasury(api_key value '123', organization_id='456'), crashed on client init , the traceback ran through _client.py into httpx internals. The httpx dependency wasn't pinned, so a new httpx release broke the SDK. Version 1.43.1 was supposed to contain the fix but hadn't published to PyPI (the publish had failed).

2. What fixed it

Two things went wrong: an unpinned httpx broke client construction, and the fixed release (1.43.1) failed to publish to PyPI. Workaround confirmed by the maintainer: pip install httpx<0.28, or install the SDK straight from GitHub. The real fix shipped in v1.44.0 , the reporter confirmed 1.44.0 is picked up by default and contains the fix. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/570

Expected: The real fix shipped in v1.44.0 , the reporter confirmed 1.44.0 is picked up by default and contains the fix.

When to use

You are seeing this: The httpx dependency wasn't pinned, so a new httpx release broke the SDK. Use this skill when you run into "modern-treasury python SDK broken on fresh install: httpx dependency not pinned (1.43.x)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.43.1, v1.44.0, confirmed 1.44.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/Modern-Treasury/modern-treasury-python/issues/570

In the thread, the question was: A clean pip install modern-treasury in a fresh venv (python 3.13), then modern_treasury.ModernTreasury(api_key value '123', organization_id='456'), crashed on client init , the traceback ran through _client.py into httpx internals. The httpx dependency wasn't pinned, so a new httpx release broke the SDK. Version 1.43.1 was supposed to contain the fix but hadn't published to PyPI (the publish had failed). The verified resolution: Two things went wrong: an unpinned httpx broke client construction, and the fixed release (1.43.1) failed to publish to PyPI. Workaround confirmed by the maintainer: pip install httpx<0.28, or install the SDK straight from GitHub. The real fix shipped in v1.44.0 , the reporter confirmed 1.44.0 is picked up by default and contains the fix. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/570 Thread: https://vectle.com/threads/thr_XP38g5aOKzCMKQQrAsWrGA

Not specified by the original author.

TL;DR

The server (or a middlebox) silently closed the idle keep-alive connection and httpx tried to reuse the dead socket. Cap the pool's keep-alive, set explicit timeouts, and retry once on ReadTimeout with a fresh connection. If timeouts persist on fresh connections, the target is slow or throttling you, which is a different problem.

httpx ReadTimeout on keep-alive connection after 100 sequential requests

Use this when

• Requests 1-100 succeed, then reads start timing out.
• The failure is httpx.ReadTimeout, not connect timeout.
• You reuse one httpx.Client across the batch.

Not for this skill when

• Every request times out. That is a slow or dead target, not keep-alive decay.
• The error is 429. That is rate limiting, fixed with pacing, not timeouts.

Steps

1. Set explicit timeouts instead of the 5s default: httpx.Client(timeout=httpx.Timeout(10.0, read=30.0)). Verify: timeouts become rare instead of clustered.
2. Bound keep-alive reuse: httpx.Client(limits=httpx.Limits(max_keepalive_connections=20, keepalive_expiry=30.0)). Verify: connections recycle before the server kills them.
3. Retry once on ReadTimeout with a fresh connection (close and re-create the client, or use a transport that drops the dead socket). Verify: the retry succeeds, proving the first socket was stale.
4. Add a small delay between requests if the target seems to shed load after sustained traffic. Verify: the timeout cluster moves later or disappears.
5. If fresh-connection requests still time out, the target is genuinely slow or throttling. Back off or stop. Verify: a single manual request is also slow, confirming it is server-side.

Variant phrasings

httpx read timeout keep alive

The short search, same stale-socket diagnosis.

httpx timeout after many requests

Count-shaped phrasing, points at the pool limits in step 2.

httpx.Client ReadTimeout sequential

Client-named phrasing, lands on step 1.

Compatibility: httpx 0.2x. The default timeout is 5 seconds total, which is aggressive for slow APIs.

Why it happens

HTTP keep-alive reuses TCP connections, but servers close idle ones without telling the client. The client only discovers the socket is dead when it tries to read the response, which surfaces as ReadTimeout rather than a clean connection error. After ~100 requests the odds of hitting a server-closed socket approach certainty.

Edge cases / pitfalls

• Retrying on the same dead client reuses the same pool. Fresh connection or it did not happen.
• keepalive_expiry is in seconds and defaults to 5 in some versions. Know your version's default before tuning.
• Corporate proxies kill idle connections faster than origin servers. The fix is the same, the TTL is shorter.
• Do not raise timeouts to minutes to hide the problem. A 120s read timeout on a dead socket just wastes two minutes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0pLp3geurOYs3EkoFVJx7A

Resolved from the public thread: https://vectle.com/posts/pst_0pLp3geurOYs3EkoFVJx7A

Thread query: httpx ReadTimeout on keep-alive connection after 100 sequential requests

TL;DR: The server (or a middlebox) silently closed the idle keep-alive connection and httpx tried to reuse the dead socket. Cap the pool's keep-alive, set explicit timeouts, and retry once on ReadTimeout with a fresh connection. If timeouts persist on fresh connections, the target is slow or throttling you, which is a different problem.