Artifactory "checksum does not match" upload in CI

Artifactory computed the SHA-256 of the received bytes and it did not match the checksum the client declared. The upload was corrupted in transit, or a checksum header was stale.

What this error means

A jf rt upload or checksum deploy fails with "Checksum error ... expected ... but received ..." and Artifactory rejects the artifact.

[Error] server response: 409 Conflict
Checksum error: received 'a1b2c3' but expected 'd4e5f6' for artifact
'libs-release-local/com/acme/app/1.0.0/app-1.0.0.jar'

Common causes

A corrupted or truncated upload

A dropped or partial transfer means the bytes Artifactory received differ from what the client hashed, so the checksum does not match.

A stale checksum in a checksum-based deploy

A checksum-first deploy sent a SHA that no longer matches the rebuilt artifact, so Artifactory rejects the association.

How to fix it

Re-run the upload cleanly

Rebuild the artifact so its bytes and checksum are current.
Re-run the upload; jf recomputes and sends the correct checksum.
If it recurs for the same file, suspect the network path, not the file.

Terminal

jf rt upload "build/app-1.0.0.jar" "libs-release-local/com/acme/app/1.0.0/"

Retry transient corruption

A one-off mismatch is usually a transient transfer issue; retrying the upload sends a fresh, correctly hashed copy.

How to prevent it

Rebuild artifacts before upload so checksums are always current.
Retry uploads on transient network failures.
Avoid reusing precomputed checksums after a rebuild.