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

Flake: sbt 1.2.8 warm-cache `update` in Dockerfile.sbt hangs until the 45-min job timeout

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

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
3/5
預估耗時
1-2 天
新手友好度
55/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
docker, github-actions, scala

研究方向

Start by reading tests/docker/Dockerfile.sbt and the workflow jobs coverage-docker (sbt) and e2e-docker (sbt); compare their warm-cache sbt update step with the successful nightly runs. On a workflow dispatch, enable the suggested sbt debug logging to identify whether resolver access stalls before choosing a timeout or retry. Done means the warm-cache build finishes reliably and a stalled resolver fails within a bounded time with useful diagnostics.

由索引模型根據 Issue 內容生成。

描述

agent:triaged ci-janitor priority:p3

docker build of tests/docker/Dockerfile.sbt hung in its warm-cache layer three times in about 90 minutes this morning (2026-10-22). Each time the job sat until its 45-min timeout-minutes killed it.

Run / attempt Job Runner Hung step Duration
39745825228 #1 coverage-docker (sbt) depot-5chxnxdgmt Build sbt image 08:17 → 09:02 (cancelled by timeout)
39745825228 #1 e2e-docker (sbt) depot-0xcx81brcg Build sbt image 08:17 → 09:02 (cancelled by timeout)
39745825228 #2 e2e-docker (sbt) depot-bdcmbfmvlt Build sbt image 09:02 → 45-min timeout

In the attempt-1 coverage-docker (sbt) log the sbt launcher fetches sbt 1.2.8 and Scala 2.12.7 in ~3 s. Then it prints nothing for 44 min:

#17 3.628 [info] Loading project definition from /tmp/warm-1.2.8/project
#17 3.709 [info] Updating ProjectRef(uri("file:/tmp/warm-1.2.8/project/"), "warm-1-2-8-build")...
2026-10-22T09:01:59Z ##[error]Step canceled by GitHub

The usual time for the whole job is ~6 min (nightly e2e-docker (sbt) on 10-19 and 10-21).

Impact: schedule and workflow_dispatch only (coverage-docker / e2e-docker); sbt-compatibility.yml has not run since 10-09. Not merge-blocking today. But each hang burns 45 runner-min per sbt leg and turns the nightly red with no diagnostic.

Likely cause (unconfirmed): sbt 1.2.8 resolves its build definition through Ivy, which has no socket read timeout. One stalled connection to a resolver (Maven Central, repo.scala-sbt.org, repo.typesafe.com) then hangs update forever instead of failing. The same layer's curl downloads all have --retry; this step has neither a retry nor a deadline.

Candidate fix for a future janitor run:

  • Pass JVM socket timeouts (-Dsun.net.client.defaultConnectTimeout / -Dsun.net.client.defaultReadTimeout) to the warm sbt update calls, so a stalled resolver fails fast and the layer can retry once.
  • First confirm which host stalls: run with -Dsbt.log.noformat=true -debug on a dispatch.

Generated by Claude Code

主要語言
Rust
星號
8
分支
1
平均合併
19 小時 9 分鐘
30 天內合併 PR
645

環境準備

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