Maven "Premature end of Content-Length" transfer in CI

By Daniel Zoghalchali·Latchkey

Maven started downloading an artifact, the server advertised a Content-Length, but the connection closed before that many bytes arrived. The transfer is incomplete, so resolution fails. This is a transport flake, not a bad request.

What this error means

Resolution fails with "Could not transfer artifact ...: Premature end of Content-Length delimited message body (expected: N; received: M)". A retry often succeeds.

mvn output

[ERROR] Failed to execute goal on project app: Could not resolve dependencies:
Could not transfer artifact org.springframework:spring-core:jar:6.1.6
from/to central (https://repo.maven.apache.org/maven2):
Premature end of Content-Length delimited message body (expected: 1,728,344; received: 902,144)

Common causes

The connection dropped mid-download

A network blip, proxy reset, or mirror hiccup closed the socket before the full artifact transferred.

A flaky or overloaded mirror

An unreliable mirror truncates responses under load, producing fewer bytes than the advertised length.

How to fix it

Retry the resolve

Re-run the failed download. A clean retry usually completes the transfer; persist ~/.m2 so completed downloads are not re-fetched.

Terminal

mvn -B -Dmaven.wagon.http.retryHandler.count=3 verify

Cache the local repository and pick a reliable mirror

Cache ~/.m2/repository and point Maven at a dependable mirror to reduce flaky transfers.

.github/workflows/ci.yml

- uses: actions/cache@v4
  with:
    path: ~/.m2/repository
    key: m2-${{ hashFiles('**/pom.xml') }}

How to prevent it

Cache ~/.m2/repository between runs.
Enable wagon HTTP retries for transient drops.
Use a stable mirror close to the runners.

Frequently asked questions

What causes ""Premature end of Content-Length""?

A network blip, proxy reset, or mirror hiccup closed the socket before the full artifact transferred.

How do I fix "Premature end of Content-Length"?

Re-run the failed download. A clean retry usually completes the transfer; persist ~/.m2 so completed downloads are not re-fetched.

Can Latchkey fix this automatically?

Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.