cargo-outdated
cargo-outdated copied to clipboard
kbknapp
`cargo-outdated` fails with "failed to download" error
I've tried both versions:
cargo install --force cargo-outdated --locked
and
cargo install --force --git https://github.com/kbknapp/cargo-outdated --locked
In both it fails with the same error type:
$ cargo outdated
error: failed to download from `https://crates.io/api/v1/crates/core-foundation/0.6.4/download`
Caused by:
failed to get 200 response from `https://crates.io/api/v1/crates/core-foundation/0.6.4/download`, got 502
$ cargo outdated
error: failed to download from `https://crates.io/api/v1/crates/winapi-x86_64-pc-windows-gnu/0.4.0/download`
Caused by:
[28] Timeout was reached (download of `winapi-x86_64-pc-windows-gnu v0.4.0` failed to transfer more than 10 bytes in 30s)
An attempt to run the command in a verbose mode results in bunch of warnings:
$ cargo outdated -v
Parsing... current workspace
Resolving... current workspace
Downloaded mach v0.3.2
Downloaded fuchsia-zircon-sys v0.3.3
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `arrayref v0.3.6` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `shell32-sys v0.1.2` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `rust-argon2 v0.7.0` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `cocoa v0.19.1` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `widestring v0.4.0` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `winapi-build v0.1.1` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `wasi v0.9.0+wasi-snapshot-preview1` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `winapi v0.2.8` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `hermit-abi v0.1.8` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `core-graphics v0.17.3` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `miow v0.2.1` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `schannel v0.1.17` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `winapi-util v0.1.3` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `cloudabi v0.0.3` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `rand_hc v0.2.0` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `malloc_buf v0.0.6` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `vcpkg v0.2.8` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `core-foundation-sys v0.6.2` within 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (download of `objc v0.2.7` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (2 tries remaining): [28] Timeout was reached (failed to download any data for `winreg v0.6.2` within 30s)
warning: spurious network error (1 tries remaining): [28] Timeout was reached (download of `cocoa v0.19.1` failed to transfer more than 10 bytes in 30s)
warning: spurious network error (1 tries remaining): [28] Timeout was reached (failed to download any data for `rust-argon2 v0.7.0` within 30s)
I see that these are the dependencies (direct and indirect) of my project, but I'm not sure why this happens. I have no issues running cargo update or cargo check and judging from docs in README to this repository, cargo-outdated relies on cargo update.
These appear to be network timeouts, are you behind a proxy?
cargo-outdated should have $HTTPS_PROXY set your communicate with the pass through to the external network.
If not what details can you give about your network setup?
Yes there was some issues with crates.io which could be causing this. Can you try again ?
These appear to be network timeouts, are you behind a proxy?
No proxy set up. Just a regular Wi-Fi connection to my router (which in turn receives the IP address from the ISP via DHCP).
$ ip addr show
...
4: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 98:af:65:dc:e4:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.8/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp1s0
valid_lft 603182sec preferred_lft 603182sec
inet6 2a02:810d:1540:1e4a:af33:c449:cb58:dd80/64 scope global dynamic noprefixroute
valid_lft 3840sec preferred_lft 1140sec
inet6 fe80::320e:6e81:6254:60a9/64 scope link noprefixroute
valid_lft forever preferred_lft forever
...
Yes there was some issues with crates.io which could be causing this. Can you try again ?
Sure. I've just retried, same error type.
error: failed to download from `https://crates.io/api/v1/crates/winapi/0.2.8/download`
Caused by:
[28] Timeout was reached (download of `winapi v0.2.8` failed to transfer more than 10 bytes in 30s)
Yeah looks like you did get it with the crates.io outage at first with this error:
Caused by: failed to get 200 response fromhttps://crates.io/api/v1/crates/core-foundation/0.6.4/download, got 502
However, you are still getting timeouts. I added winapi v0.2.8 to a test project but was able to see the new version just fine (even behind my work proxy!). I've really only seen this when you cannot connect to GitHub or did not set the CLI to use network options (e.g. proxies), do you have any issues or special setup to clone anything from GitHub?
No, no special configuration. I've installed rustup a couple days ago (also without any special configuration) and just fetched the cargo-outdated from GitHub with a regular git clone.
cargo update && cargo check also works fine on my project (it also fetches the crates from crates.io).
@cmdln Any additional information you could give might be helpful, I cannot recreate this and from the errors I'm stumped.
@application-developer-DA could you also try running with RUST_LOG=debug? Try this in a small replicated project, otherwise there will be a lot of output and the true error might be buried.
I thought it might be my VPN but I disabled that and am still seeing network errors like this.
12:23 $ cargo outdated -R
warning: Feature style of package crossterm has been obsolete in version 0.16.0
warning: Feature style of package crossterm has been obsolete in version 0.16.0
error: failed to download from `https://crates.io/api/v1/crates/rusoto_secretsmanager/0.43.0/download`
Caused by:
[28] Timeout was reached (failed to download any data for `rusoto_secretsmanager v0.43.0` within 30s)
@cmdln can you try with export RUST_LOG=debug as well? Again do this in a smaller repository it will output a lot of stuff (e.g. a toml containing only something likerand = "0.6").
Right now I'm not sure what's blocking/slowing the connections unless it's crates.io itself, but I am not seeing this.
I'm wondering if the issue may be caused by an executable not trying to fetch using all available IP addresses for a given host. Could it be that the tool just tries the first available address which it resolves to and does not re-try the download in case it fails to fetch something using the provided address?
$ getent hosts crates.io
2600:9000:2099:ae00:c:7ed3:240:93a1 crates.io
2600:9000:2099:be00:c:7ed3:240:93a1 crates.io
2600:9000:2099:ec00:c:7ed3:240:93a1 crates.io
2600:9000:2099:7400:c:7ed3:240:93a1 crates.io
2600:9000:2099:8400:c:7ed3:240:93a1 crates.io
2600:9000:2099:8200:c:7ed3:240:93a1 crates.io
2600:9000:2099:ca00:c:7ed3:240:93a1 crates.io
2600:9000:2099:4c00:c:7ed3:240:93a1 crates.io
$ host crates.io
crates.io has address 13.32.8.252
crates.io has address 13.32.8.244
crates.io has address 13.32.8.42
crates.io has address 13.32.8.167
crates.io has IPv6 address 2600:9000:2099:4c00:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:ca00:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:8200:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:8400:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:7400:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:ec00:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:be00:c:7ed3:240:93a1
crates.io has IPv6 address 2600:9000:2099:ae00:c:7ed3:240:93a1
I don't think that's the underlying error here, but I could definitely be wrong! Did you try running with RUST_LOG=debug to see if there's some low level network errors that are reported?
I tried with debug logs, but I had the same experience @cmdln had: it worked without any issues on smaller repositories.
Now I'm getting a slightly different error by the way:
error: failed to download from `https://crates.io/api/v1/crates/http/0.2.0/download`
Caused by:
[1] Unsupported protocol (Received HTTP/0.9 when not allowed
)
I found the smallest repository where the problem is reproducible and reproduced it, then used sed to filter some unrelated messages, but it's still a 213 KB log file which ends with the following lines:
[2020-03-24T17:43:19Z DEBUG cargo::core::package] downloading base64 v0.12.0 as 0
[2020-03-24T17:43:19Z DEBUG cargo::core::package] aho-corasick v0.7.10 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] http_machine v0.0.1 (/tmp/cargo-outdatedhcDe56/http_machine) doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] input_buffer v0.3.1 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] url v2.1.1 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] hermit-abi v0.1.8 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] httparse v1.3.4 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] env_logger v0.7.1 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] winapi-i686-pc-windows-gnu v0.4.0 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] winapi-util v0.1.3 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] unicode-bidi v0.3.4 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] matches v0.1.8 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] itoa v0.4.5 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] libc v0.2.68 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] thread_local v1.0.1 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] unicode-normalization v0.1.12 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] winapi v0.3.8 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::core::package] percent-encoding v2.1.0 doesn't need a download
[2020-03-24T17:43:19Z DEBUG cargo::sources::registry::remote] loading config
[2020-03-24T17:43:19Z DEBUG cargo::core::package] downloading http v0.2.0 as 1
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 4344 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 16342 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 24 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 16342 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 24 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 16342 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 24 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 - 1863 bytes of data
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 0 finished with Ok(())
[2020-03-24T17:43:20Z DEBUG cargo::core::package] 1 finished with Err(Error { description: "Unsupported protocol", code: 1, extra: Some("Received HTTP/0.9 when not allowed\n") })
[2020-03-24T17:43:20Z DEBUG cargo] exit_with_error; err=CliError { error: Some(Error { description: "Unsupported protocol", code: 1, extra: Some("Received HTTP/0.9 when not allowed\n") }
failed to download from `https://crates.io/api/v1/crates/http/0.2.0/download`), unknown: false, exit_code: 1 }
error: failed to download from `https://crates.io/api/v1/crates/http/0.2.0/download`
Caused by:
[1] Unsupported protocol (Received HTTP/0.9 when not allowed
)
That's interesting..
@application-developer-DA could you post the Cargo.toml that reproduces this and the other error for you?
@application-developer-DA and @cmdln I just updated cargo-outdated to use the latest version of cargo API (v0.43.1) can you try the latest version of cargo-outdated (v0.9.8)?
Thanks!!
For most of the (smaller) repositories which did not work with cargo-outdated and triggered the errors I mentioned in my previous comments it works well now, thanks!
But the bigger repositories still have this problem.
error: failed to download from `https://crates.io/api/v1/crates/wasm-bindgen-backend/0.2.60/download`
Caused by:
[28] Timeout was reached (download of `wasm-bindgen-backend v0.2.60` failed to transfer more than 10 bytes in 30s)
I extracted the relevant part into a separate Cargo.toml which I can use to reproduce the error. Interesting enough, the error is not always the same.
[package]
name = "test_cargo_outdated"
version = "0.1.0"
authors = ["Daniel Abramov <[email protected]>"]
edition = "2018"
[target.x86_64-pc-windows-gnu.dependencies]
winreg = { version = "0.6.2", default-features = false }
widestring = "0.4.0"
[target.x86_64-pc-windows-gnu.dependencies.winapi]
version = "0.3.7"
features = [
"basetsd",
"debug",
"dwmapi",
"errhandlingapi",
"libloaderapi",
"minwindef",
"processthreadsapi",
"rpcdce",
"securitybaseapi",
"shellapi",
"sspi",
"sysinfoapi",
"winbase",
"windef",
"windowsx",
"winerror",
"wingdi",
"winhttp",
"winnt",
"winuser",
]
[target.x86_64-apple-darwin.dependencies]
block = "0.1.6"
cocoa = "0.19.0"
core-foundation = "0.6.4"
core-foundation-sys = "0.6.2"
core-graphics = "0.17.3"
dispatch = "0.1.4"
mach = "0.3.2"
objc = "0.2.6"
[dependencies]
app_dirs = "1.2.1"
backtrace = "0.3.34"
base64 = "0.10.1"
byteorder = "1.3.2"
env_logger = "0.6.2"
fnv = "1.0.6"
foreign-types = "0.3.0"
futures = "0.1.28"
hyper = "0.12.33"
hyper-tls = "0.3.2"
image = "0.22.1"
itertools = "0.8.0"
lazy_static = "1.3.0"
libc = "0.2.60"
log = "0.4.8"
native-tls = "0.2.3"
regex = "1.2.1"
resize = "0.3.0"
rustc-demangle = "0.1.15"
semver = "0.9.0"
serde = "1.0.98"
serde_derive = "1.0.98"
slog = "2.5.2"
slog-async = "2.3.0"
slog-envlogger = "2.1.0"
slog-scope = "4.1.2"
slog-stdlog = "3.0.5"
slog-term = "2.4.1"
smallvec = "1.1.0"
time = "0.1.42"
tokio = "0.1.22"
tokio-tungstenite = "0.9.0"
toml = "0.5.1"
url = "=2.1.0"
zip = "0.5.2"
When checking this exact Cargo.toml file with the crate.io's version of cargo-outdated (v0.9.8) on MacOS (Mojave 10.14.6) I don't see any errors at all :(, I also checked on my work VPN tunnel (much smaller pipe than my home network) and did not see any timeouts, or errors that caused it to fail.
I ran 10x in a row to double check and nothing.
What machine (OS) are you running this one normally?
On Mac OS X I also don't have any issues, that's why I suspected the handling of IPv4/IPv6 addresses or something like this (see https://github.com/kbknapp/cargo-outdated/issues/212#issuecomment-600326277).
The issue is reproducible on my primary Arch Linux system. The only my assumption would be that the underlying function used by cargo-outdated is gethostbyname() and not getaddrinfo() which means that it probably reads NSS to properly resolve the address, which in turn may lead to slightly different order of resolved names as compared to getaddrinfo(). I'm not sure if this can be an issue though.