Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proxy.golang.org: returning old versions when the proxy knows of a newer version #46369

Closed
leighmcculloch opened this issue May 25, 2021 · 6 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@leighmcculloch
Copy link
Contributor

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

$ go version
go version go1.16.3 linux/amd64

Does this issue reproduce with the latest release?

Yes, occurs on Go 1.16.4 too.

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

go env Output
$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN="/home/vscode/.local/bin"
GOCACHE="/home/vscode/.cache/go-build"
GOENV="/home/vscode/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="0"
GOMOD="/workspaces/.../go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3201939647=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go get github.com/stellar/mddiffcheck@latest
go get: downgraded github.com/stellar/mddiffcheck v0.0.0-20210525162741-cfbe68afa074 => v0.0.0-20210525064236-6b157d2a519a

$ GOPROXY=direct go get github.com/stellar/mddiffcheck@latest
go get: upgraded github.com/stellar/mddiffcheck v0.0.0-20210525064236-6b157d2a519a => v0.0.0-20210525162741-cfbe68afa074

$ go get github.com/stellar/mddiffcheck@latest
go get: downgraded github.com/stellar/mddiffcheck v0.0.0-20210525162741-cfbe68afa074 => v0.0.0-20210525064236-6b157d2a519a

$ go get github.com/stellar/mddiffcheck@v0.0.0-20210525162741-cfbe68afa074
go get: upgraded github.com/stellar/mddiffcheck v0.0.0-20210525064236-6b157d2a519a => v0.0.0-20210525162741-cfbe68afa074

$ go get github.com/stellar/mddiffcheck@latest
go get: downgraded github.com/stellar/mddiffcheck v0.0.0-20210525162741-cfbe68afa074 => v0.0.0-20210525064236-6b157d2a519a

The latest version of the tool is v0.0.0-20210525162741-cfbe68afa074.

The old version of the tool is v0.0.0-20210525064236-6b157d2a519a.

What did you expect to see?

I expected that the proxy.golang.org Go proxy would return the latest commit for a tool once it knew of the latest commit of the tool.

I expected that using the defaults for GOPROXY, which prefers proxy.golang.org, would be more convenient than customizing the GOPROXY.

What did you see instead?

The proxy.golang.org Go proxy returning an old version of the tool, even after it has successfully delivered the latest version of the tool.

@seankhliao
Copy link
Member

Note the presence of a later commit doesn't necessarily mean it is on the default branch which is what latest maps to

@leighmcculloch
Copy link
Contributor Author

In this case the later commit does live on the default branch.

If I get the default branch explicitly it gets the later commit, but then if I get latest again, it downgrades again.

$ go get github.com/stellar/mddiffcheck@main 
go get: upgraded github.com/stellar/mddiffcheck v0.0.0-20210525064236-6b157d2a519a => v0.0.0-20210525162741-cfbe68afa074

$ go get github.com/stellar/mddiffcheck@latest
go get: downgraded github.com/stellar/mddiffcheck v0.0.0-20210525162741-cfbe68afa074 => v0.0.0-20210525064236-6b157d2a519a

If this is behaving as intended, the behavior is surprising and not intuitive.

@leighmcculloch
Copy link
Contributor Author

Note that the later commit is 35 minutes old but is still not being picked up by latest.

According to https://proxy.golang.org:

explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue.

@mknyszek
Copy link
Contributor

CC @heschi @hyangah @katiehockman

@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 25, 2021
@mknyszek mknyszek added this to the Unreleased milestone May 25, 2021
@katiehockman
Copy link
Contributor

Thanks for filing the issue. At this point, it looks like the @latest endpoint is showing the newer commit like you would expect: https://proxy.golang.org/github.com/stellar/mddiffcheck/@latest

So this particular issue has resolved itself. However, we can take a look at our logs to determine whether something went wrong on our end. I was able to confirm that we had fetched it within ~5 minutes of the commit: it was committed at 2021-05-25T16:27:41Z and we fetched it at 2021-05-25T16:31:04.655554Z. It would be surprising behavior if the @latest endpoint would take more than a minute or two to provide that fresh data.

@katiehockman
Copy link
Contributor

To follow-up, I want to expand the FAQ entry you linked:

If you want new code to be immediately available in the mirror, then first make sure there is a semantically versioned tag for this revision in the underlying source repository. Then explicitly request that version via go get module@version. The new version should be available within one minute. Note that if someone requested the version before the tag was pushed, it may take up to 30 minutes for the mirror's cache to expire and fresh data about the version to become available. If the version is still not available after 30 minutes, please file an issue.

If someone wants a particular commit to show up very quickly in the /list and /@latest results for their repo, then they should tag that version, then explicitly fetch it from the proxy after the tag has been pushed.

I still don't have an explanation for why it took >35 minutes, since that shouldn't happen, even for a pseudoversion. But please let us know if that happens again and provide as many timestamps as possible so we can debug on our end. Thanks!

@golang golang locked and limited conversation to collaborators May 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants