proxy.golang.org: slow resolution of commit already pulled through the proxy

[myitcv]

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

$ go version
go version go1.18.5 linux/arm64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/tmp/tmp.5OypHrxqu8/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/tmp/tmp.5OypHrxqu8"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.18.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/tmp.nw51kzT8Zs/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 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3953696208=/tmp/go-build -gno-record-gcc-switches"

What did you do?

cd $(mktemp -d)
go mod init mod.com
go get -x cuelang.org/go@748a68589747fed6273d6338eb7e275a4fb116c6

What did you expect to see?

A quick resolution via the proxy, as that commit has already been pulled through the proxy.

What did you see instead?

# get https://proxy.golang.org/cuelang.org/go/@v/748a68589747fed6273d6338eb7e275a4fb116c6.info
# get https://proxy.golang.org/cuelang.org/@v/748a68589747fed6273d6338eb7e275a4fb116c6.info
# get https://proxy.golang.org/cuelang.org/@v/748a68589747fed6273d6338eb7e275a4fb116c6.info: 404 Not Found (1.453s)
# get https://proxy.golang.org/cuelang.org/go/@v/748a68589747fed6273d6338eb7e275a4fb116c6.info: 200 OK (6.713s)
# get https://proxy.golang.org/cuelang.org/go/@v/list
# get https://proxy.golang.org/cuelang.org/go/@v/list: 200 OK (0.066s)
go: added cuelang.org/go v0.4.4-0.20220622094641-748a68589747

Note the 6.7s for returning a 200.

This delay appears to happen "some hours" after previously running the go get command. i.e. almost feels like a cache goes cold, that commit gets evicted, which then makes a subsequent go get run more slowly.

[myitcv]

To add a bit more detail on rough timings of when this commit was pulled through the proxy via go get -x cuelang.org/go@748a68589747fed6273d6338eb7e275a4fb116c6:

• 2022-06-22 - first pull through the proxy
• ...
• 2022-09-09 am (UTC)
• 2022-09-09 pm (UTC)

It's the last of these go get's that I was expecting to be near instantaneous.

But then I should be clear that my expectations are not grounded in any form of reality of what the proxy does with respect to commit queries and caching.

I couldn't find any docs at https://proxy.golang.org/ talking about caching of commit queries. Depending on the resolution if this issue it might make sense to add an FAQ there.

[mknyszek]

CC @golang/tools-team

[findleyr]

FWIW https://proxy.golang.org/cuelang.org/go/@v/748a68589747fed6273d6338eb7e275a4fb116c6.info just took 16s for me...

Without looking in too much detail, I'd assume that the proxy doesn't know which non-canonical versions are stable: it doesn't know that this version is a commit hash and not a branch.

You should get cache hits for v0.4.4-0.20220622094641-748a68589747

[findleyr]

CC @bcmills @suzmue @hyangah

I think this is WAI: the proxy probably should be in the business of guessing whether non-canonical versions are stable, or in eagerly refreshing all version aliases.

@myitcv can you expand on how you happened to encounter this and/or the problems it caused?

[hyangah]

As the -x output shows, this involves the .info endpoint queries. The GOPROXY protocol spec reads:

$base/$module/@v/$version.info

... The Version field is required and must contain a valid, canonical version (see Versions). The $version in the request path does not need to be the same version or even a valid version; this endpoint may be used to find versions for branch names or revision identifiers. However, if $version is a canonical version with a major version compatible with $module, the Version field in a successful response must be the same.

Caching behavior when $version is non-canonical is unspecified.

[myitcv]

@findleyr

I think this is WAI: the proxy probably should be in the business of guessing whether non-canonical versions are stable, or in eagerly refreshing all version aliases.

That's a good point re branches, I hadn't considered that. Thanks!

can you expand on how you happened to encounter this and/or the problems it caused?

Just in regular development, debugging an issue. I happened to restart my machine between these two debugging sessions, so used command history to re-run the go get. Was surprised it took quite so long, hence raised an issue to verify whether there was an issue here or not (like #50158, #53906, #49916)

@hyangah

Caching behavior when $version is non-canonical is unspecified.

Thanks for confirming. It might not warrant an FAQ if this is the first time the question has been asked, so I'll leave to you to decide!

I'll close this as @findleyr confirmed things are working as intended here.