Failed sending data to the peer (Connection died, tried 5 times before giving up)

When cargo check runs in a github action it downloads most of the dependencies, but occasionally fails on one of them. It fails on different ones on each run (tested it around 5 times).

Downloading dependencies works locally, but when running in a github action it fails:

Downloaded sys-info v0.5.10
  Downloaded strum_macros v0.19.4
  Downloaded proc-macro-error v1.0.4
  Downloaded pin-utils v0.1.0
  Downloaded v_escape v0.15.0
  Downloaded uuid v0.7.4
  Downloaded typeable v0.1.2
  Downloaded syn v1.0.73
  Downloaded strum v0.20.0
error: failed to download from ``
Error: failed to download from ``
Caused by:
  [55] Failed sending data to the peer (Connection died, tried 5 times before giving up)
Error: The process '/usr/share/rust/.cargo/bin/cargo' failed with exit code 101

I really don’t know what’s causing this. Does anyone have a hint for me?

Thank you in advance :slight_smile:

I am hitting similar issues over here Update nalgebra and the rest of dependencies to have the crates compile by mpizenberg · Pull Request #33 · rust-cv/cv · GitHub. I am wondering if there are network limits we are running into? I am getting failed dependency downloads. To mitigate this, I am trying to use rust-cache to cache some of the source so it doesn’t need to be redownloaded. If anyone knows of a proper fix, that would be awesome.

I am also running into this often requiring the entire workflow to be restarted

Hi there!
A colleague found a solution for this. Seems like it’s a problem with nightly. This change in our ci file fixed it:


Version locking to nightly-2021-07-05 seems to have resolved this error for me as well. However, this doesn’t appear to be limited to GitHub Actions.

I’m running cargo +nightly fmt --all -- --check in a GitLab-CI custom runner on an EKS cluster with NAT gateway egress. Sometimes it works, sometimes it errors with Error during execution of cargo metadata: Updating git repository, then proceeds to reinstall a bunch of packages eventually bombing out with the same error cause [55].

Thanks for the tip.

Is anyone aware if there is a tracking issue for this problem if it is a bug in Cargo?