cmd/go: go get tries to download non-existing commit

[ayzu]

Please answer these questions before submitting your issue. Thanks!

What did you do?

mkdir project
cd project
export GO111MODULE=on
go mod init project
go get github.com/micro/go-plugins@v1.0.0

What did you expect to see?

successful download of dependency

What did you see instead?

go: finding github.com/nats-io/nats.go v1.8.2-0.20190607221125-9f4d16fe7c2d
go: github.com/nats-io/nats.go@v1.8.2-0.20190607221125-9f4d16fe7c2d: unknown revision 9f4d16fe7c2d
go: error loading module requirements

Does this issue reproduce with the latest release (go1.12.7)?

yes

System details

go version go1.12.7 darwin/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/a8327/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/a8327/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.6/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.6/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/09/xght07y913s83cqxlwc_x3z017ny38/T/go-build408435640=/tmp/go-build -gno-record-gcc-switches -fno-common"

Note:
The case is that github.com/micro/go-plugins@v1.0.0 has a mod file https://github.com/micro/go-plugins/blob/v1.0.0/go.mod which requires github.com/nats-io/go-nats v1.7.0

Repository github.com/nats-io/go-nats is archived and probably redirects to https://github.com/nats-io/nats.go.

However, github.com/nats-io/nats.go does not have commit 9f4d16fe7c2d at all. Probably, it was here at some point but then was removed. So go get tries download non-existing commit from the master branch instead of latest tag 1.8.1 in github.com/nats-io/nats.go.

The same error will pop up, if we specify the dependency in go.mod and run go build.

[bcmills]

This issue does not reproduce for me with go1.13beta1 and the provided steps.

project$ go1.13beta1 mod init project
go: creating new go.mod: module project

project$ go1.13beta1 get github.com/micro/go-plugins@v1.0.0
go: finding github.com/micro/go-plugins v1.0.0
go: downloading github.com/micro/go-plugins v1.0.0
go: extracting github.com/micro/go-plugins v1.0.0

project$

Nor does it reproduce if the @v1.0.0 suffix is dropped, presumably because proxy.golang.org still has the missing commit in its cache:

project$ go1.13beta1 get github.com/micro/go-plugins
go: finding github.com/micro/go-plugins v1.1.1
[…]
go: finding github.com/micro/micro v1.7.1-0.20190627121529-410a2eba67f1

project$

The failure mode with go1.13beta1 and GOPROXY=direct is different, apparently due to a tag deleted from k8s.io/client-go. (The error message below is accurate: I checked https://github.com/kubernetes/client-go, and there really is no such tag at this point.)

project$ go1.13beta1 mod init project
go: creating new go.mod: module project

project$ export GOPROXY=direct

project$ go1.13beta1 get github.com/micro/go-plugins@v1.0.0
go: finding github.com/micro/go-plugins v1.0.0
go get: github.com/micro/go-plugins@v1.0.0 requires
        github.com/micro/go-config@v0.14.0 requires
        k8s.io/client-go@v2.0.0-alpha.0.0.20190126161006-6134db91200e+incompatible: invalid pseudo-version: preceding tag (v2.0.0-alpha.0) not found

project$

I can reproduce the failure mode you observed with go1.13beta1, GOPROXY=direct, and no @v1.0.0 suffix:

project$ go1.13beta1 get github.com/micro/go-plugins
go: finding github.com/micro/go-plugins v1.1.1
go get: github.com/micro/go-plugins@v1.1.1 requires
        github.com/nats-io/nats.go@v1.8.2-0.20190607221125-9f4d16fe7c2d: unknown revision 9f4d16fe7c2d

project$

That comes from an explicit requirement here, and that error message is also accurate: the repository at https://github.com/nats-io/nats.go contains no such commit.

---

Sorry, but this is not a bug in the go command. The proxy.golang.org mirror is continuing to cache this content for the moment (as designed), and also as designed, GOPROXY=direct is reporting the accurate state of the underlying repositories. With the caching proxy bypassed, there isn't much we can do if someone deletes an existing tag or force-pushes their repo to remove a commit or version that is already in use.

[bcmills]

CC @derekcollison

[derekcollison]

There is no 1.8.2 release, so this is from a commit on master most likely that may no longer exist.

[bcmills]

Yes: judging by the pseudo-version, it is specifically a commit on master at some point after the v1.8.1 tag.

[ayzu]

Yes, I guess that's exactly the case. However, my question is why it tries to find this non-existing commit, instead of using existing latest tag 1.8.1? Wouldn't be that expected behaviour?

[bcmills]

@ayzu, builds using Go modules are expected to be 100% reproducible. If the configuration required for a reproducible build cannot be obtained, that results in an error rather than a silent change in behavior.

Note that you can explicitly change the behavior by adding a replace directive in your main module, such as

replace github.com/nats-io/nats.go v1.8.2-0.20190607221125-9f4d16fe7c2d => github.com/nats-io/nats.go v1.8.1

[bcmills]

(And note that, at least for now, you can explicitly set GOPROXY=https://proxy.golang.org and to be able to build both versions of github.com/micro/go-plugins in their original configuration.)

[ayzu]

@derekcollison @bcmills

There is no 1.8.2 release, so this is from a commit on master most likely that may no longer exist.

Yes, this is the exact issue. It tries to find non-existing commit and fails. Is it expected behaviour?

The dependency in go.mod file is github.com/nats-io/go-nats v1.7.0 This repository redirects to github.com/nats-io/nats.go

From wiki:

In this section, "latest" is the latest version with a semver tag, or the latest known commit if there are no semver tags.

In my understanding go get was supposed to download the latest tag (1.8.1 > 1.7.0) or at least the exact 1.7.0 version. Instead, it tries to download non-existing commit (not tag).

Moreover, this commit v1.8.2-0.20190607221125-9f4d16fe7c2d is not even the latest one. It was removed at some part in the past, and there were some more commits after. According to https://github.com/nats-io/nats.go/commits/master, the latest commit on master was yesterday, 11 July.

Could you please elaborate why go get has chosen it?

[derekcollison]

Is it listed in the go.sum?

[ayzu]

Is it listed in the go.sum?

You mean in go-plugins repository? https://github.com/micro/go-plugins/blob/6eef94c098315c5cfc03334fbcb5f8d43b1ca04a/go.sum#L523

Yes, it is listed:

github.com/nats-io/go-nats v1.7.0 h1:oQOfHcLr8hb43QG8yeVyY2jtarIaTjOv41CGdF3tTvQ=
github.com/nats-io/go-nats v1.7.0/go.mod h1:+t7RHT5ApZebkrQdnn6AhQJmhJJiKAvJUio1PiiCtj0=

[ayzu]

@bcmills @derekcollison

There is something more interesting. If I have a direct dependency github.com/micro/go-plugins@v1.0.0 which has go.mod which requries github.com/nats-io/go-nats v1.7.0, go build will fail with error github.com/nats-io/nats.go@v1.8.2-0.20190607221125-9f4d16fe7c2d: unknown revision 9f4d16fe7c2d. So instead of downloadinggithub.com/nats-io/go-nats v1.7.0 it will redirect to different repository github.com/nats-io/nats.go and will try to download non-existing (and not-latest commit). Note, that version of go-plugins is v1.0.0 and two different repos go-nats and nats.go.

But if try to download the exact dependency github.com/nats-io/go-nats v1.7.0 directly: go get github.com/nats-io/go-nats@v1.7.0. It will successfully download the required version without redirection to the other repository.

module local/dep

go 1.12

require (
	github.com/nats-io/go-nats v1.7.0 // indirect
	github.com/nats-io/nats.go v1.7.0 // indirect
	github.com/nats-io/nkeys v0.1.0 // indirect
	github.com/nats-io/nuid v1.0.1 // indirect
)

So, it looks like behaviour differs for those use cases.

[bcmills]

@ayzu, it seems pretty clear that the version in question is coming from the go.mod file in github.com/micro/go-plugins v1.1.1. If that's not the version of go-plugins you expected, it may be due to #29121, which is fixed in go1.13beta1.