Current BehaviourOS platform
Python version
Dependencies
import asyncio
import httpx
async def get():
r = await httpx.get("https://eodhistoricaldata.com")
print(r)
asyncio.run(get())Causes the following error: However using the synchronous client does not raise any error: Expected Behaviour
|
Answered by
graingert
Apr 5, 2022
Replies: 13 comments 19 replies
|
Contacted the EOD Historical Data team and they suggested using their http URL (which works on my end) import asyncio
import httpx
async def get():
async with httpx.AsyncClient() as c:
r = await httpx.get("http://nonsecure.eodhistoricaldata.com/")
print(r)
asyncio.run(get()) |
0 replies
|
Doesn't replicate for me... >>> import httpx
>>> httpx.get("https://eodhistoricaldata.com")
<Response [200 OK]> |
2 replies
|
The report as shown doesn't make much sense. For instance... r = await httpx.get("https://eodhistoricaldata.com")
# The line you've shown here won't work at all.
# `httpx.get` is a regular function call. Not async.
# You can only use async with `httpx.AsyncClient()`(You'll get the same error that @graingert has shown) |
|
@tomchristie thanks for the response. I made a mistake writing out the snippet in the comments. I actually had @graingert's: import asyncio
import httpx
async def get():
async with httpx.AsyncClient() as c:
r = await c.get("https://eodhistoricaldata.com")
print(r)
asyncio.run(get())And it was this snippet with the AsyncClient that produced the IPV4 error. Really sorry about the confusion. But I did in fact get this error 2 days ago, though it seems it was probably some slow-to-update DNS record on EOD's side that might have cause this. Thanks for the quick response! |
|
running the demo I get: |
2 replies
|
with this: import asyncio
import httpx
async def get():
async with httpx.AsyncClient() as c:
r = await c.get("https://eodhistoricaldata.com")
print(r)
asyncio.run(get())I get: |
|
Thank you @graingert for the quick response. I made a mistake writting the snippet. But the code that produced the error 2 days ago was the snippet that you have above with |
Answer selected by
topher-lo
|
Update: See my comment below, this was a mixup on my end and I don't think httpx is misbehaving. @tomchristie @graingert I'm seeing the same error but with post, and I don't think the issue is related to async vs sync client. Our code, simplified, does this: client = httpx.AsyncClient(
base_url="https://vision.googleapis.com/v1",
auth=OAuthTokenAuth(...),
)
async def run():
response = await client.post(
"/images:annotate",
timeout=...,
json=...,
)I noticed this similar issue on uvicorn, in the fixing PR it seems like this is related to some underlying API not accepting hostnames when IPv6 addresses are expected? |
3 replies
|
Can you make a runable example and include the traceback? |
|
I haven't successfully reproduced this myself, I'm seeing this in logs from a QA/staging environment. I just realized I misinterpreted this in Sentry. The error I was seeing wasn't uncaught, but was reported because a timeout occurred in one of its The And the real uncaught (timeout) exception happens within this call to Sorry for the mixup, it now seems to me like httpx behaving as expected. Let me know if you want more info about the stack trace. |
|
We are seeing a similar issue when running our code specifically on EC2 instances. It doesn't occur immediately -- sometimes it can take up to 18 minutes before we see the exception. |
|
We are running into this error, too, however it only occurs for the Mac users in our engineering team. with On other platforms the requests just resolve fine. Very interesting to observe that for the affected developers, running an async shell via |
2 replies
Thanks @larsblumberg. |
|
Here is the entire traceback: To my eyes While I can't see the value of Judging from the error message and odd variable value for |
|
Any fix for this yet? Running EDIT: it works fine when run outside of docker. I guess it's a docker problem then. Weird that the exception occurs after some time and not immediately |
0 replies
|
I'm having the same issue with What solved the issue for me was to specify the dns when running the container with the I hope it helps. |
0 replies
|
I don't know if this is really the same error but here's the stack trace that I am getting. The weird thing is that this seems to be platform-dependent. I don't have the problem on MacOS at all. This only happens on my Linux machine (details posted below the stack trace). Stack traceVersion informationLinux host (gets the error): MacOS host (works fine): |
3 replies
|
Thanks @megamorf... You're seeing a timeout during the TCP connection. I've raised a discussion on the I wonder if there's anything we can do in
|
|
Thanks! I would like to add that this issue only appears if I do 3+ async calls with one client to the same domain. I'll probably have to check how to stress test my local DNS resolver to narrow down the problem. |
|
@megamorf did you get any lead? |
|
Any fix for this error? I keep getting it randomly with the Github API. The following is the stacktrace (for me it happens on Linux): |
0 replies
|
I keep getting this randomly |
2 replies
|
Same |
|
You're seeing a DNS timeout resulting in an If you're either able to give an easily replicable example, tell us which URL you're accessing, or provide some more information about how frequently you're seeing this issue that'd be helpful. Also prompts the thought that DNS caching at the level of the connection pooling would probably be a great idea. |
|
@tomchristie FYI we don't get a Timeout, but our stacktrace looks like this: |
0 replies
|
Is this related with python/cpython#112169 ? 🤔 |
2 replies
|
Sure sounds like |
|
Saturation of the thread pool would also explain #3084 |
|
We're getting a similar Exception with the following stack trace below. The top-level Exception is httpx.ConnectError but it seems the underlaying cause for all of this is a string being passed to the ip_address that's part of the Python distribution. I suspect this is an issue in anyio passing a hostname string instead of an ip address string for some reason but I haven't really investigated this thoroughly. |
3 replies
|
The stacktrace is misleading. See... agronholm/anyio#580 There's a proposed fix on that discussion, though it doesn't appear to have been escalated into an issue/pr yet. I'd expect contributions there would be welcome. |
|
Also we can clearly improve the error messaging for different types of connection failure. Eg DNS resolution errors, server connection errors, SSL setup errors. If anyone would like to escalate an issue for that? |
|
After some digging I realized that for some reason 1.1.1.1 was not able to resolved the target domain in 1 out of 10 times. I switched to 8.8.8.8 and this issue was gone for me. Not really a fix overall but works in my limited and specific case. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
running the demo I get: