Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの 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 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
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
フォーク
2
平均マージ
19時間 9分
マージ済み PR(30日)
641

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

SocketDev/socket-patch のほかの issue

SocketDev/socket-patch の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。