Redeploying the same coordinates with different content returns 201 but keeps serving the old file

Open
  • Is something wrong?
#551 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@aevnsvi is already working on this.

Since Oct 20, 2026.

  • #552 by @aevnsvi — open

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend, databases

Research direction

Start with the MavenArtifact identity and upload serializer lookups described in the issue, then trace how repository versions select artifacts by path. Compare the metadata content checksum handling mentioned in the issue and inspect tests for deploying the same coordinates twice. Done means changed content is served in a new repository version, while identical redeploys remain a no-op—or the upload returns an error instead of claiming success.

Written by the indexing model from the issue text.

Description

Version
pulp_maven main (0fc577a), pulpcore 3.122.2.

Describe the bug
A second deploy of the same coordinates with different content is accepted with 201 Created but discarded. The repository keeps serving the file deployed first, and no new repository version is created.

MavenArtifact is identified by its coordinates and filename alone. The second upload therefore resolves to the existing content unit, finds its file slot occupied, and leaves it untouched. The upload serializer has the same lookup.

Snapshot development is the most visible victim, because it republishes the same coordinates by design. mvn deploy reports success while the repository keeps the previous build. Nothing tells the publisher that the new build was not stored.

Related: #309.

To Reproduce

  1. Create a repository and a distribution: 
    http POST :8080/pulp/api/v3/repositories/maven/maven/ name=demo
http POST :8080/pulp/api/v3/distributions/maven/maven/ name=demo base_path=demo repository=<repository href>
  2. Deploy one file, then a different file to the same path: 
    P=com/example/demo/1.0-SNAPSHOT/demo-1.0-SNAPSHOT.jar
echo first  | curl -s -o /dev/null -w '%{http_code}\n' -u admin:password -X PUT --data-binary @- :8080/pulp/maven/demo/$P
echo second | curl -s -o /dev/null -w '%{http_code}\n' -u admin:password -X PUT --data-binary @- :8080/pulp/maven/demo/$P
    Both answer 201.
  3. curl :8080/pulp/content/demo/$P returns first. The repository has only the version created by the first upload.

Expected behavior
The second deploy either replaces the file the repository serves, with a new repository version, or is refused with an error. It should not report success while discarding the upload. Redeploying identical content can stay a no-op.

Additional context
I have a patch that makes a redeploy replace the previous file:

  • The file's checksum becomes part of the artifact's identity, as it already is for metadata content. Identical content still resolves to the same unit.
  • The repository key fields stay without the checksum, so different content displaces the unit it supersedes. Every repository version keeps exactly one artifact per path.

Refusing redeploys of released versions is a reasonable policy too, but it is a separate feature. This patch only stops the silent discard. I can open it as a PR.

Dominant language
Python
Stars
5
Forks
30
Avg merge
2d 7h
Merged PRs (30d)
36

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pulp/pulp_maven

All issues in pulp/pulp_maven

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.