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 摘要。