Pull-through cache: `.whl.metadata` (PEP 658) requests raise `ValueError: True is not in list` on 3.29.0 — residual case of #1083

[andrzej-jedrzejewski-knauf]

Version

• pulp_python 3.29.0
• pulpcore 3.108.0
• Installation: container image (Pulp operator on Kubernetes)

Describe the bug

On a pull-through PyPI distribution, when a client requests <wheel>.whl.metadata (PEP 658), pulp-content raises ValueError: True is not in list in pulp_python/app/utils.py:get_project_metadata_from_file and returns a 5xx / aborted stream. A direct GET also surfaces a misleading 404 with an upstream URL that doesn't exist (https://pypi.org/simple/<package>/<wheel>.whl.metadata — PEP 658 metadata files live next to the wheel on files.pythonhosted.org/packages/<hash>/..., not under the simple index path).

This appears to be a residual case of #1083. PR #1086 fixed the .whl fetch path by passing suffix=filename into the temp file, so endswith(".whl") matches. But when the requested artifact is the .whl.metadata companion, init_from_artifact_and_relative_path is still called, path.name ends in .metadata, the temp file ends in .metadata, and DIST_EXTENSIONS has no .metadata entry — so .index(True) raises.

To Reproduce

1. Configure a pull-through PyPI distribution:

pulp python remote create       --name pypi --url https://pypi.org/ --policy on_demand
pulp python distribution create --name pypi-proxy --base-path pypi --remote pypi                                                                                                                                                                      

2. From a clean state (no cached package), request the PEP 658 metadata file directly:

curl -sk -o - -w "HTTP %{http_code}\n" \               
"https://<pulp>/pulp/content/<domain>/pypi/simple/ruff/ruff-0.12.12-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata"                                                                                                               

Equivalent: run uv lock / uv sync against this distribution from a cold uv cache — uv issues .whl.metadata requests per PEP 658.
3. Observe a 404 to the client and the following traceback in pulp-content logs:

File "pulpcore/content/handler.py", line 1033, in _save_artifact                                                                                                                                                                                      
content = c_type.init_from_artifact_and_relative_path(artifact, rel_path)                                                                                                                                                                           
File "pulp_python/app/models.py", line 223, in init_from_artifact_and_relative_path
data = artifact_to_python_content_data(path.name, artifact, domain=get_domain())                                                                                                                                                                    
File "pulp_python/app/utils.py", line 273, in artifact_to_python_content_data
metadata = get_project_metadata_from_file(temp_file.name)                                                                                                                                                                                           
File "pulp_python/app/utils.py", line 195, in get_project_metadata_from_file
pkg_type_index = [filename.endswith(ext) for ext in extensions].index(True)                                                                                                                                                                         
ValueError: True is not in list                        

Expected behavior

Either:

• The .metadata companion is served from upstream (fetched alongside / extracted from the wheel) so PEP 658 works through the pull-through cache, or
• The request returns a clean 404 without invoking the python-package metadata extractor on a non-package file.

In both cases get_project_metadata_from_file should not be called with a filename whose extension isn't in DIST_EXTENSIONS.

Additional context

• Original report and partial fix: Pull-through catching PyPI and using uv leads to metadata issues #1083, PR Fix pull-through metadata serving and saving #1086 ("Fix pull-through metadata serving and saving", merged 2026-02-06; backported to 3.24 in [PR #1086/7fc17563 backport][3.24] Fix pull-through metadata serving and saving #1089).
• Related: Metadata file does not match the wheel metadata (PEP 658) #1101 (PR [PULP-1200] Fix edge case when creating metadata file #1102) — metadata file mismatched against wheel.
• 3.29.0 source for artifact_to_python_content_data confirms the suffix=filename fix from Fix pull-through metadata serving and saving #1086 is present, so the .whl path works; the .whl.metadata path bypasses that protection because filename itself ends in .metadata.
• Likely fix direction: short-circuit the companion .metadata case before artifact_to_python_content_data is called (e.g. in init_from_artifact_and_relative_path when relative_path ends in .metadata), since those bytes already are the metadata and don't need extracting.
• Effect on clients: uv resolutions against the pull-through distribution silently report "only <old-cached-version> is available" because per-version metadata fetches all crash server-side; only versions whose metadata happens to already be cached in Postgres remain visible.

[gerrod3]

@andrzej-jedrzejewski-knauf The url you are using is wrong. It should be https://<pulp>/pypi/<domain>/pypi/simple/ruff/ruff-0.12.12-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata. This routes to our /pypi apis which properly handle pull-through requests and correctly generates the right url to redirect to the content app.

The problem is that we don't protect against improper use of pull-through caching. I think we need to add a check to get_remote_artifact_url that returns a 400 error when using an improper URL.