ArtifactFileField.pre_save spuriously rejects uploads named 'artifact*' when MEDIA_ROOT is empty

[dralley]

Summary

ArtifactFileField.pre_save uses a fragile prefix check to decide whether an incoming file is already inside artifact storage:

https://github.com/pulp/pulpcore/blob/main/pulpcore/app/models/fields.py#L69-L73

is_in_artifact_storage = file.name.startswith(os.path.join(settings.MEDIA_ROOT, "artifact"))

When settings.MEDIA_ROOT is "" — which is the case for object-storage backends (azure, s3, etc.) — this collapses to:

file.name.startswith("artifact")

file.name for a fresh upload is the client-provided filename. Any uploaded file whose name begins with the substring artifact (e.g. artifact-foo-1.0-1.noarch.rpm) therefore matches, already_in_place is False, and pre_save raises:

ValueError: The file referenced by the Artifact is already present in Artifact storage.
Files must be stored outside this location prior to Artifact creation.

which surfaces to the client as a 500 Internal Server Error on POST /pulp/<domain>/api/v3/artifacts/.

Impact

Any user uploading an artifact whose filename starts with artifact to a deployment with an empty MEDIA_ROOT (object storage) gets a spurious 500. The bug is filename-dependent and backend-dependent, so it is easy to miss.

How it was discovered

A pulp_rpm functional test (test_domains.py::test_artifact_from_file) built an RPM named artifact-<hex>-1.0-1.noarch.rpm and uploaded it via the artifacts endpoint. It failed only on the azure job (empty MEDIA_ROOT); the sibling test using a content- prefix passed.

Suggested fix

The prefix check is meant to detect files that are already physically in artifact storage. It should not rely on a bare startswith against a possibly-empty settings.MEDIA_ROOT, and it arguably should consider the current domain's actual storage location rather than the global setting. Options:

• Normalize/join paths and compare path components instead of doing a raw string prefix match.
• Guard against an empty MEDIA_ROOT so the check does not degenerate to startswith("artifact").

Environment

• Reproducible with any object-storage backend where MEDIA_ROOT is empty (azure/s3), including per-domain FileSystem storage where the global settings.MEDIA_ROOT is still empty.

[dralley]

Minimal reproducer

Deployment with an object-storage backend (so settings.MEDIA_ROOT == ""), e.g. azure/s3.

The only thing that matters is that the uploaded file's name starts with artifact.

With the pulpcore Python client bindings

import tempfile, os
from pulpcore.client.pulpcore import ApiClient, Configuration, ArtifactsApi

cfg = Configuration(host="http://localhost:24817", username="admin", password="password")
client = ApiClient(cfg)
artifacts = ArtifactsApi(client)

# The filename is what triggers the bug -- it starts with "artifact".
path = os.path.join(tempfile.mkdtemp(), "artifact-repro.txt")
with open(path, "wb") as f:
    f.write(b"hello world\n")

# 500 Internal Server Error:
#   ValueError: The file referenced by the Artifact is already present in Artifact storage.
artifacts.create(file=path)

# Control: any other prefix works fine.
ok = os.path.join(tempfile.mkdtemp(), "repro.txt")
with open(ok, "wb") as f:
    f.write(b"hello world\n")
artifacts.create(file=ok)  # 201 Created

With httpie / curl

echo "hello world" > /tmp/artifact-repro.txt
http --form POST :24817/pulp/api/v3/artifacts/ file@/tmp/artifact-repro.txt   # -> 500

echo "hello world" > /tmp/repro.txt
http --form POST :24817/pulp/api/v3/artifacts/ file@/tmp/repro.txt            # -> 201

The same happens through any content-upload path that lands in ArtifactFileField.pre_save (e.g. pulp file content upload with a file whose basename starts with artifact).