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

Flake: nightly poetry hosted rollback fails on one transient PyPI request (UpstreamClient has no retry)

未关闭
#1,650 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@mikolalysenko 已经在做这个了。

开始于 2026年10月21日。

  • #1652 来自 @mikolalysenko —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
rust

调研方向

Start with crates/socket-patch-core/src/patch/redirect/upstream/client.rs and inspect get_json_authorized and download, then compare their error handling with api::client::network_error_detail and the retry behavior in api::retry and send_json_request. The reproduction is crates/socket-patch-cli/tests/e2e_vex_build/poetry.rs:898; first establish how to classify the transport error, then determine whether a bounded retry is warranted. Done means the cause is visible in errors and any retry policy is covered by relevant tests.

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

描述

agent:triaged ci-janitor priority:p3

Nightly e2e-extended (ubuntu-latest, e2e_vex_build, poetry:: --ignored, 1.1.15) failed once on a single failed PyPI request during hosted rollback.

Evidence

  • Run https://github.com/SocketDev/socket-patch/actions/runs/39101574188 (schedule, main, 2026-10-18), job 117599202945
  • poetry::poetry_hosted_fresh_install_then_manifestless_vex panicked at crates/socket-patch-cli/tests/e2e_vex_build/poetry.rs:898: rollback exited 1 with hosted_restore_refused:
    cannot restore pkg:pypi/[email protected] to its upstream registry entry: six==1.16.0: GET https://pypi.org/pypi/six/1.16.0/json: error sending request for url (...)
  • The other 3 poetry tests in the same job reached PyPI fine seconds earlier. The 10-19 nightly passed on the same code.
  • Frequency: 1 of the last 12 nightlies. It has not been seen on PR or merge_group runs (this leg is nightly-only).

Root cause (partly known)
UpstreamClient (crates/socket-patch-core/src/patch/redirect/upstream/client.rs) sends each registry lookup once. get_json_authorized and download turn any transport error into a final GET {url}: {e} with no retry. The patch API client does retry dropped connections and 429/503 (api::retry, send_json_request). Because the message keeps only reqwest's top-level text, the log can't tell us the transport error class (DNS, reset, timeout).

Proposed fix (not started: the evidence was too thin this run)

  1. Format registry-lookup errors with the cause chain, the same way api::client::network_error_detail does, so the next occurrence is classifiable.
  2. If it recurs as a dropped connection or a 429/503, give UpstreamClient's GETs the same bounded ApiRetry policy that send_json_request uses (is_retryable_transport plus is_retryable_status, the shared retry window). A user's hosted rollback hits the same failure mode.

Filed by the hourly CI janitor; the job log expires, so the signature is quoted above.


Generated by Claude Code

主要语言
Rust
星标
8
派生
1
平均合并
17 小时 56 分钟
30 天内合并 PR
594

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

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

SocketDev/socket-patch 的其他 Issue

查看 SocketDev/socket-patch 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

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