Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
#1,650 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
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
平均合併
19 小時 28 分鐘
30 天內合併 PR
628

環境準備

  • 沒有 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 摘要。