cmd/go, proxy.golang.org: go install serving stale code from main branch

[matthewmueller]

What version of Go are you using (go version)?

$ go version
go version go1.18.1 darwin/amd64

Does this issue reproduce with the latest release?

Not sure. It's hard to reproduce once it's working again. I'd assume it's still a problem.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/m/Library/Caches/go-build"
GOENV="/Users/m/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/m/dev/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/m/dev"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/m/dev/src/github.com/matthewmueller/hack/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/4f/tcxcr6_55v9bp38d8g4hjlf80000gn/T/go-build3367796448=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I tried locally running:

go install github.com/livebud/bud@main

Shortly after publishing to main (maybe 3-5 minutes) because of a failure in CI.

What did you expect to see?

I expected it to go out to Github, download the latest code from the main branch and install it.

What did you see instead?

I saw it succeed and serve stale code. This also appears to be what happened in CI too. I was able to trigger a refresh by running the following:

GOPRIVATE=* go install github.com/livebud/bud@main

However, this isn't intuitive because bud is a public repository.

The core of this issue may be related to #42809, though when I tried GONOSUMDB=* go install github.com/livebud/bud@main, it still served stale code. Maybe because it was cached locally?

[dmitshur]

I expected it to go out to Github, download the latest code from the main branch and install it.

In your go env the GOPROXY value is set to "https://proxy.golang.org,direct". That configuration means it first tries the Go module mirror (not GitHub), and falls back to direct only if the module mirror reports 404/410. See the first entry in the FAQ of https://proxy.golang.org/ for information about timing and caching of newly committed versions.

[matthewmueller]

Thanks for the fast reply @dmitshur!

In your go env the GOPROXY value is set to "https://proxy.golang.org,direct"

I believe this is the default, so most people will have this configuration. Just noting that for the rest of my comment.

In order to improve our services' caching and serving latencies, new versions may not show up right away.

It sounds like it's working as expected, though I'd argue it's a poor user experience. It seems like the Go Proxy is trying to save on a request to Github for branches. This is unexpected when you compare it to other package managers like NPM.

Personally, I expect a proxy to be transparent, something I don't really need to think about. This design decision requires me to consider it. It's also not the first place you think to look.

Questions that came up while I was trying to figure this out:

• "Did I forget to push up to Github?"
• "Should I be using @latest perhaps?"
• "Is there something weird with my module cache? go install is finishing rather quickly... did it even check Github?"

Feel free to close if this decision is set in stone at this point, I think I'll be aware of this next time around. My hope is that Go Modules can reach the UX of NPM or Homebrew while still delivering on the promise of reproducible builds!

[seankhliao]

Duplicate of #38065