Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#8,217 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@gigi206 已经在做这个了。

开始于 2026年10月13日。

  • #8218 来自 @gigi206 —— 未关闭

评估

难度
3/5
预计耗时
半天
新手友好度
66/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
backend

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Python
星标
606
派生
174
平均合并
16 小时 44 分钟
30 天内合并 PR
107

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

pulp/pulpcore 的其他 Issue

查看 pulp/pulpcore 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。