Every Docker build (make test, make lint, make check, script/cibuild) runs RUN go mod download with no time limit, in three places in Dockerfile. When one connection to the module proxy stalls, the step waits until the kernel gives up on it: one such step hung for about 55 minutes, and a second one stalled on a connection retransmitting to the proxy's port 443. Normally the step takes 13 to 24 seconds. Builds of the same tree share the step while it runs, so a single stalled download held every vaultik build on the host for the whole time, and when it finally fails, every build attached to it fails as if the gate were red.
Definition of done
Each go mod download in Dockerfile is bounded by a time limit well above its normal duration (a few minutes) and retried a small, fixed number of times before the build fails, so a stalled connection costs minutes, not an hour.
A build that still cannot download its modules fails with a message that says the module download failed, not a test or lint failure.
Nothing else in the build changes: the same pinned images, the same --no-cache gate, no cache mounts.
Model: opus-5-5
Every Docker build (`make test`, `make lint`, `make check`, `script/cibuild`) runs `RUN go mod download` with no time limit, in three places in `Dockerfile`. When one connection to the module proxy stalls, the step waits until the kernel gives up on it: one such step hung for about 55 minutes, and a second one stalled on a connection retransmitting to the proxy's port 443. Normally the step takes 13 to 24 seconds. Builds of the same tree share the step while it runs, so a single stalled download held every vaultik build on the host for the whole time, and when it finally fails, every build attached to it fails as if the gate were red.
**Definition of done**
- Each `go mod download` in `Dockerfile` is bounded by a time limit well above its normal duration (a few minutes) and retried a small, fixed number of times before the build fails, so a stalled connection costs minutes, not an hour.
- A build that still cannot download its modules fails with a message that says the module download failed, not a test or lint failure.
- Nothing else in the build changes: the same pinned images, the same `--no-cache` gate, no cache mounts.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 12:44:14 +02:00
#354 runs each of the three go mod download steps in Dockerfile under a 180-second limit, tries it up to three times, and then fails the step with module download failed: giving up after 3 attempts.
Model: opus-5-5
https://git.eeqj.de/sneak/vaultik/pulls/354 runs each of the three `go mod download` steps in `Dockerfile` under a 180-second limit, tries it up to three times, and then fails the step with `module download failed: giving up after 3 attempts`.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Every Docker build (
make test,make lint,make check,script/cibuild) runsRUN go mod downloadwith no time limit, in three places inDockerfile. When one connection to the module proxy stalls, the step waits until the kernel gives up on it: one such step hung for about 55 minutes, and a second one stalled on a connection retransmitting to the proxy's port 443. Normally the step takes 13 to 24 seconds. Builds of the same tree share the step while it runs, so a single stalled download held every vaultik build on the host for the whole time, and when it finally fails, every build attached to it fails as if the gate were red.Definition of done
go mod downloadinDockerfileis bounded by a time limit well above its normal duration (a few minutes) and retried a small, fixed number of times before the build fails, so a stalled connection costs minutes, not an hour.--no-cachegate, no cache mounts.Model: opus-5-5
#354 runs each of the three
go mod downloadsteps inDockerfileunder a 180-second limit, tries it up to three times, and then fails the step withmodule download failed: giving up after 3 attempts.Model: opus-5-5