[slayerjain]

Problem

proxy.golang.org now and then resets an HTTP/2 stream partway through a module download:

go: golang.org/x/text@v0.31.0: read "https://proxy.golang.org/...": stream error: stream ID 187; INTERNAL_ERROR; received from peer

The next attempt succeeds. But every Go sample's Dockerfile here fetched its modules exactly once, using a bare go mod download, a bare go mod tidy, or a go build that fetches what it needs. One reset therefore fails the image build. It also fails the CI lane of whichever keploy repo was running docker build on the sample: keploy/keploy's workflows and other keploy CI clone this repo at main and build these Dockerfiles. This repo's own build.yml has the same exposure through its bare go build ./....

Changes

1. fix: retry the Go module fetch in every Go sample's Dockerfile (27 Dockerfiles). Each fetch now runs in a loop: 5 attempts, 5-20s apart, then the build fails.

   RUN n=0; until go mod download; do n=$((n+1)); [ "$n" -lt 5 ] || exit 1; echo "go mod download failed (attempt $n), retrying in $((n*5))s"; sleep $((n*5)); done
   

   • The 19 bare go mod downloads and go-grpc's two go mod tidys run in the loop.
   • echo-sql, gin-redis, mux-mysql, sse-svelte and users-profile fetched inside go build. They now run the looped go mod download first.
   • nethttp-mysql's go mod download || true ignored a failed fetch and left it to an un-retried go mod tidy. Both are looped now.

   A module fetch is idempotent and fails only because of the network, so retrying it is safe. A missing module or a bad go.mod fails every attempt and still fails the build.

2. fix(gin-redis, gin-pulsar): build them on a Go their go.mod accepts. Neither image built before this PR. gin-redis's go.mod needs Go 1.23 but the image was golang:1.20; gin-pulsar's needs Go 1.25 but the image was golang:1.23.

3. ci: retry each sample's module fetch before building it. build.yml now runs go list -deps ./... in a loop, the same 5 attempts, before each go build ./.... go list -deps loads the same packages go build loads, so it fetches nothing more.

4. ci: check that every Go module fetch in a Dockerfile runs in a bounded retry loop. .github/scripts/check_go_fetch_retried.py, run by a new dockerfile-fetch job in build.yml after a self-test on 26 fixtures, reads every Dockerfile. In each stage:

   • every fetch (go mod download/tidy/vendor, go install/get/run at a version) must be the condition of an until loop that fails the build when it runs out;
   • the first go build/test/run/vet/generate/list must come after a looped module fetch, in the stage, in one it is built FROM, or in one whose module cache it copies;
   • a RUN in exec form or with a here-document that runs go is refused, since it cannot be verified.

   It flags all 27 Go Dockerfiles on main (50 lines) and none on this branch. keploy enterprise pipeline 11675 failed on go-grpc's RUN go mod tidy ("stream error: stream ID 167; INTERNAL_ERROR"), which this PR loops.

Rebased onto main (07c5ba9) on 2026-10-17. No Go Dockerfile added since this PR was opened is missed: the guard reads them all.

Verification

• All 27 changed Dockerfiles were built on a test machine: 25 built. gin-pulsar and gin-redis failed for the same reason the unchanged Dockerfiles fail, and both build after commit 2. docker build --check reports no warnings on any of them.
• A GOPROXY was set up that cuts the first download of one module partway:
  • The unchanged go-docker-timefreeze and go-grpc server Dockerfiles fail with unexpected EOF (on golang-jwt/jwt v5.3.0 and on grpc v1.69.2). The looped ones recover on the second attempt.
  • The same holds for build.yml's step: the old step fails on go-docker-timefreeze, and the new one recovers.
• build.yml's step was run as written, with Go 1.27.0 and an empty module cache: all 44 modules build, both with and without this change.
• keploy/keploy's and keploy's other CI were searched for sed edits to these Dockerfiles. Two edit them: one rewrites go-docker-timefreeze's RUN CGO_ENABLED=0 GOOS=linux go build -o /main . line, and keploy's gin_mongo macOS script rewrites gin-mongo's EXPOSE 8080. This PR leaves both lines unchanged.