-
Notifications
You must be signed in to change notification settings - Fork 731
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase or adjust scope of default HTTP timeout #1921
Comments
I would expect that a server only sends an HTTP Timeout response if the connection is idle for too long, which makes me wonder if increasing the timeout solves the problem or only hides the root cause. |
Yeah good point, I wonder if we're setting the wrong timeout? We shouldn't be enforcing this timeout when data transfer is actively occurring. |
FWIW the default in PIP is 15 seconds https://github.com/pypa/pip/blob/main/src/pip/_internal/cli/cmdoptions.py#L294, so I'm not sure uv's 30? second default is at fault. |
Could it be that we need to reduce the number of parallel requests? It could also be that they timeout because some cpu intensive task is blocking the main thread, esp. with something large like pytorch. |
It seems like the next steps are to:
|
It looks like we're using a deadline for the full request not a read timeout as desired. We need this functionality to be added upstream. |
@mariosasko - How often are you seeing this? We'll ship the HTTP timeout change soon (this week for sure), but I'm still wondering if there's something else going on here and would use |
@charliermarsh It's pretty consistent, e.g., see the first two commit's CI runs in huggingface/datasets#6811 (it's more likely to happen than not based on recent CI runs). PS: Not sure if this info is valuable, but both Windows and Ubuntu GH runners are susceptible to this issue |
OK thanks. I'm gonna do some testing using that CI workflow. |
So the first issue I ran into is that Windows sometimes fails with pytest missing, because the "Install dependencies" step silently fails:
We can make that not silent by changing the shell configuration (so that it exits as soon as one command fails, rather than proceeding). But I'm not sure why it's failing in the first place. 503 hitting that static endpoint? |
This reverts commit 00f8d47. uv has fixed astral-sh/uv#1921, which should resolve timeout issues with pytorch/nvidia packages.
This reverts commit 00f8d47. uv has fixed astral-sh/uv#1921, which should resolve timeout issues with pytorch/nvidia packages.
This reverts commit 00f8d47. uv has fixed astral-sh/uv#1921, which should resolve timeout issues with pytorch/nvidia packages.
This reverts commit 00f8d47. uv has fixed astral-sh/uv#1921, which should resolve timeout issues with pytorch/nvidia packages.
Our current HTTP timeout is not sufficient for some large packages e.g.
torch
Increasing the timeout has a downside for people that have network problems while downloading smaller packages, e.g. it will wait longer before surfacing a problem.
What does pip use for a default timeout?
The text was updated successfully, but these errors were encountered: