Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Content app answers 404 instead of 502 when the remote of on-demand content is unavailable

Abierto
  • ¿Algo no está bien?
#8,217 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@gigi206 ya está trabajando en esto.

Desde el 13/10/2026.

  • #8218 de @gigi206 — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
Medio día
Aptitud para principiantes
66/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
backend

Línea de trabajo

Start in Handler._stream_content_artifact in the content app, where the loop over RemoteArtifact downloads ends by raising HTTPNotFound; SKIPPABLE_EXCEPTIONS and REMOTE_CONTENT_FETCH_FAILURE_COOLDOWN also govern that loop. Run test_delete_remote_on_demand, test_remote_artifact_url_update and test_remote_content_changed_with_on_demand, which must keep passing as 404. Done means a connection failure or 5xx from the remote yields 502 while the other failure cases stay 404, and the open question about 429 is settled.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Version
pulpcore 3.119.2 with pulp_file, installed from source with oci-env. The behaviour is the same on main (475caac) and dates back to 3.0.0.

Describe the bug
When a ContentArtifact has no Artifact (on-demand or streamed content, or content whose artifact was reclaimed), the content app streams it from its RemoteArtifact objects. When none of them can be fetched, Handler._stream_content_artifact raises HTTPNotFound whatever the reason: a remote that cannot be reached or answers with a server error gets the same 404 as content missing upstream.

The docstring of _stream_content_artifact contradicts itself: its description says that "if all RemoteArtifact downloads raise exceptions, an HTTP 502 error is returned to the client", while its Raises section, like the code, gives HTTPNotFound. It has been so since 3.0.0; the user documentation does not mention this case.

Clients then take a transient upstream outage for missing content. For example, pip retries 500, 502, 503, 520 and 527 but not 404, so with pulp_python packages synced with the default on_demand policy, a short outage fails the install at once, with a 404 pointing at the package.

To Reproduce

  1. Sync a file repository with the on_demand policy from a fixture server, and distribute it.
  2. Make the fixture server unavailable: close the connections, or answer 503 for the files.
  3. Download a file from the distribution: 404 Not Found.

Expected behavior
502 Bad Gateway when at least one remote could not be reached or answered with a server error (5xx). 404 for any other failure, as today, e.g. no RemoteArtifact, remotes answering 404, 410 or another 4xx, UnsupportedDigestValidationError, RemoteArtifact objects in their failure cooldown (REMOTE_CONTENT_FETCH_FAILURE_COOLDOWN).

Open question: should a 429 Too Many Requests from the remote, which is transient too, also give a 502?

Additional context

  • The tests asserting a 404 (test_delete_remote_on_demand, test_remote_artifact_url_update, test_remote_content_changed_with_on_demand) cover those other cases and pass unchanged with the fix.
  • pulp_container calls _stream_content_artifact directly for registry blobs, which would get a 502 too. None of the active content plugins (pulp_ansible, pulp_container, pulp_deb, pulp_gem, pulp_hugging_face, pulp_maven, pulp_npm, pulp_python, pulp_r, pulp_rpm, pulp_rust, pulp_trustify, pulp_workflow) nor pulp-service catches this 404 or asserts it in its tests.
  • Nothing in pulpcore catches this 404 to fall back elsewhere: the content cache stores neither response, and the instrumentation middleware records the status, so the content.request_duration metrics and deployments alerting on the 5xx rate of the content app will count upstream outages there.
  • TimeoutException, raised by the downloader on timeouts, is not one of the exceptions skipped by this loop (SKIPPABLE_EXCEPTIONS) and is left unchanged.

I reproduced it in an oci-env container with pulpcore 3.119.2 and pulp_file installed from source: once the remote closed the connections or answered 503, the distribution answered 404 for the on-demand file.

Drafted with AI assistance, reviewed by me.

Lenguaje dominante
Python
Estrellas
606
Forks
174
Merge medio
16 h 44 min
PR fusionados (30 d)
107

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pulp/pulpcore

Todos los issues de pulp/pulpcore

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.