release fails when proxy hasn't indexed a freshly pushed tag yet #28

New issue

Open

opened 2026-05-02 00:49:32 +02:00 by heiko · 0 comments

heiko commented

2026-05-02 00:49:32 +02:00

Owner

Symptom

When releasing from a freshly pushed semver tag (e.g. git push --tags && gogogo release --commit v1.2.3), the very first call to go mod download module@v1.2.3 may fail because proxy.golang.org (or a private proxy) has not yet indexed the new tag.

Where

internal/builder/verify.go → ResolveModuleVersion, called from internal/cmd/release/release.go → executeFromClone. The proxy query is a single shot — there is no retry/poll.

Why this is a bug, not just a quirk

With the default GOPROXY=proxy.golang.org,direct the request silently falls back to direct mode and works, masking the issue.
With a proxy-only setup (GOPROXY=https://proxy.example.com with no direct), the release fails immediately on what is actually a transient condition.
The package internal/goproxy already provides CheckVersion for exactly this case (poll until the proxy returns 200) but it is unused by the release flow.

Suggested fix

Before calling ResolveModuleVersion for a stable semver tag, poll the proxy with goproxy.CheckVersion(ctx, module, tag) (bounded by the existing 120 s context). For pseudo-versions / branch builds the new commit-SHA-anchored proxy query (branch ai-claude-fix-proxy) makes this less critical, but a short bounded poll there too would not hurt.

Related

Sibling fix on branch ai-claude-fix-proxy addresses a different but adjacent issue (clone-vs-proxy commit divergence for branch builds).

**Symptom** When releasing from a freshly pushed semver tag (e.g. `git push --tags && gogogo release --commit v1.2.3`), the very first call to `go mod download module@v1.2.3` may fail because `proxy.golang.org` (or a private proxy) has not yet indexed the new tag. **Where** `internal/builder/verify.go` → `ResolveModuleVersion`, called from `internal/cmd/release/release.go` → `executeFromClone`. The proxy query is a single shot — there is no retry/poll. **Why this is a bug, not just a quirk** - With the default `GOPROXY=proxy.golang.org,direct` the request silently falls back to `direct` mode and works, masking the issue. - With a proxy-only setup (`GOPROXY=https://proxy.example.com` with no `direct`), the release fails immediately on what is actually a transient condition. - The package `internal/goproxy` already provides `CheckVersion` for exactly this case (poll until the proxy returns 200) but it is unused by the release flow. **Suggested fix** Before calling `ResolveModuleVersion` for a stable semver tag, poll the proxy with `goproxy.CheckVersion(ctx, module, tag)` (bounded by the existing 120 s context). For pseudo-versions / branch builds the new commit-SHA-anchored proxy query (branch `ai-claude-fix-proxy`) makes this less critical, but a short bounded poll there too would not hurt. **Related** Sibling fix on branch `ai-claude-fix-proxy` addresses a different but adjacent issue (clone-vs-proxy commit divergence for branch builds).

heiko added the

Kind/Bug

label

2026-05-02 00:49:32 +02:00

heiko referenced this issue

2026-05-02 08:47:42 +02:00

fix: anchor clone-vs-proxy verification to the same commit #29