Suprious network errors when downloading source code

[thomaseizinger]

Steps to reproduce the bug with the above code

We've recently hit a fairly high number of spurious network errors in the use of cargo semver-checks. Not sure how much we can do about them but here are some links:

• https://github.com/libp2p/rust-libp2p/actions/runs/5782762586/job/15670522857#step:41:715
• https://github.com/libp2p/rust-libp2p/actions/runs/5782756485/job/15670482772#step:41:715
• https://github.com/libp2p/rust-libp2p/actions/runs/5782750882/job/15670392407

Actual Behaviour

Expected Behaviour

To run cargo semver-checks in CI without spurious errors.

Generated System Information

Hard to obtain for CI but we are running version 0.22.1: https://github.com/libp2p/rust-libp2p/blob/master/.github/actions/cargo-semver-checks/action.yml#L10

Build Configuration

No response

Additional Context

No response

[obi1kenobi]

It seems that GitHub was also having some sort of network or system outage very close to the same time — possibly related.
https://twitter.com/boshen_c/status/1688431701888999424

Interestingly, this also seems to have uncovered an underlying bug in cargo involving some incorrect string slicing, presumably in some error case where the server responds in an unexpected way: https://github.com/rust-lang/cargo/blob/0.72.1/src/cargo/ops/registry.rs#L715

I can report the cargo bug upstream. That might end up resolving the problem — I'd be surprised if cargo doesn't already have built-in retries for spurious network blips. Since this error happens during our cargo metadata call, the better place to trigger a retry is within cargo itself.

[thomaseizinger]

Thanks for reporting it upstream, I think we can close this then :)