Beta: disable HTTPX connection pooling on the default client#1248
Beta: disable HTTPX connection pooling on the default client#1248richardm-stripe wants to merge 1 commit intobetafrom
Conversation
|
Are we sacrificing real-world performance to fix unit tests? |
|
In a sense? I don't consider our own test cases to be a part of the "real world", but I do think that users writing tests is an important real world use case for us. The tradeoff here is to reduce friction for (some) users writing tests, at the expense of requiring more work from users who want to minimize resource usage (and changing the default to be more wasteful for users who haven't thought about either). HTTPX makes a similar design decision itself, i.e. if you use the globals and go |
|
Maybe we can do something similar to how we handle connection pooling for stripe-python/stripe/_http_client.py Lines 478 to 480 in 341b23f Maybe there is some concept of a "event-loop-local" variable. |
|
Oh interesting, I just read https://github.com/encode/httpx/issues/2058#issuecomment-1960608385 where @Zac-HD is recommending that httpx do that very thing, but upstream. |
|
I'm going to go ahead and close unmerged, I think it's premature & so far it looks like the user having the event loop troubles is happy to work around it. There's no real reason we couldn't address this later. |
A user reported some friction using
asyncmethods withunittestwhich tries to run each test in an isolated event loop.This is because HTTPX attempts to re-use connections by default, and re-using a connection across two different event loops triggers an error.
We can avoid the error by disabling connection pooling. This causes requests to succeed in more circumstances, at the expense of making requests more wasteful and hurting performance. Users who wish to avoid this should initialize their own http client, e.g.
stripe.default_http_client = stripe.HTTPXClient()