Self-Healing CI: Auto-Retrying a Maven Central Timeout
A Maven resolve that times out fetching a jar hit a slow or congested repository moment, not a broken dependency -- the same coordinate resolves on a retry.
The problem
A Maven build fails because resolving a dependency from Maven Central timed out or reset mid-download. The coordinate is valid and the artifact exists; the request hit a congested repository or a brief network blip. A human re-runs the build and the same dependency resolves cleanly.
[ERROR] Failed to read artifact descriptor for com.example:lib:jar:1.4.2
Could not transfer artifact ... from/to central: Connection timed outWhy it happens
Each missing dependency is fetched over its own HTTP request to the repository, so a single congested moment or a momentary 5xx on one of many transfers can time out a resolve even though the artifact is present and intact at the source.
It is transport flakiness, not a dependency error: the coordinate is correct and the same jar downloads cleanly once the request is retried or served from a warm mirror.
The manual fix
Manual mitigations for a Maven Central timeout:
- Re-run the build to retry the resolve.
- Configure a repository manager or mirror to front Maven Central and absorb blips.
- Tune Maven connection/read timeouts and rely on the resolver’s retry where available.
mvn -B -Dmaven.wagon.http.retryHandler.count=3 -Dmaven.wagon.httpconnectionManager.ttlSeconds=60 installHow this gets automated
A Maven Central timeout carries a recognizable transient signature -- a timeout or reset on a transfer, not a 404 -- and the safe response is to retry the resolve, ideally onto a mirror. A self-healing CI pipeline detects the download failure, retries dependency resolution, and only escalates if the coordinate is genuinely missing, distinguishing a slow repository moment from a real dependency problem.