Self-Healing CI: Auto-Retrying a NuGet Restore Network Blip
A NuGet restore that fails partway hit a network blip on one of many feed requests, not a missing package -- the same restore completes on a retry.
The problem
A dotnet restore / nuget restore fails because a request to the package feed timed out or reset mid-download. The package and version exist; one of many feed requests hit a transient network problem. A human re-runs the build and the restore completes cleanly.
error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json
The operation was canceled (request timed out)Why it happens
A restore makes many independent requests to the feed -- the service index plus each package -- so the more packages a project has, the more transfers can hit a brief network blip and fail even though every package is present at the source.
It is transport flakiness, not a package problem: the versions are correct and the same restore completes once the failed requests are retried.
The manual fix
Manual mitigations for a NuGet restore blip:
- Re-run the build to retry the restore.
- Cache the NuGet packages folder between runs so packages are not re-fetched each time.
- Use a private feed or upstream proxy to absorb public-feed blips.
dotnet restore || (sleep 5 && dotnet restore)How this gets automated
A NuGet restore blip carries a recognizable transient signature -- a timeout or reset on a feed request, not a missing-package error -- and the safe response is to retry the restore. A self-healing CI pipeline detects the failure, retries package resolution, and only escalates if a package is genuinely unavailable, distinguishing a momentary blip from a real feed problem.