cmd/go: go get mysteriously (incorrectly?) downgrades a dependency for no reason I can find

[maxb]

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

$ go version
go version go1.20.4 linux/amd64

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="amd64"
GOBIN="/home/maxb/.local/bin"
GOCACHE="/home/maxb/.cache/go-build"
GOENV="/home/maxb/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/maxb/.cache/go-modules"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/maxb/.cache/go-path"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/maxb/code/vault/sdk/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build764324405=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ git clone https://github.com/hashicorp/vault
$ cd vault/sdk
$ git checkout 155003aa0cc054701096444b480bc7ab43d187b2     # Exact commit on 'main' at the time of writing
$ go get github.com/hashicorp/errwrap@v1.1.0

What did you expect to see?

No output and no changes caused by the go get command, as it is just re-stating an arbitrary existing module that is already present in go.mod already, at the version it is already present at.

What did you see instead?

go: downgraded github.com/google/tink/go v1.7.0 => v1.6.1

I am confused, I have no idea why Go is deciding to downgrade a seemingly unrelated module.

Considering the named module on the go get command line did not change version at all, it doesn't make sense to me that go get should be enforcing other up/downgrades.

Additionally, if I run:

$ go get github.com/google/tink/go@v1.7.0

to have go get undo the spurious change, then it does so:

go: upgraded github.com/google/tink/go v1.6.1 => v1.7.0

without making any other changes, thus showing there is not a pre-existing dependency conflict.

[seankhliao]

resolved on tip.

[maxb]

Please re-open - not resolved.

As I said there is no conflict, because, as I said at the end of the initial message:

• The requested version of github.com/hashicorp/errwrap (v1.1.0) is the version already in go.mod - I deliberately selected a no-change operation to showcase the inexplicable downgrade.

• Explicitly re-upgrading github.com/google/tink/go back to the version before the downgrade, again using go get, succeeds without any conflicts.

[maxb]

@Nasfame I don't see that message when I run that command! Have you any special settings in your environment to make it be displayed?

[maxb]

Um, actually, did you run that command exactly as it is shown in your screenshot? Because it's broken - it's missing a v before the version number, causing Go to return an entirely different error:

go: github.com/google/tink/go@1.7.0: invalid version: unknown revision 1.7.0

[maxb]

@Nasfame I suppose you're trying to help but so far you've convinced @seankhliao to close this issue based on a suggestion that doesn't help, and followed it up with a screenshot that can't be reproduced.

Could you get this issue reopened please?

[seankhliao]

As mentioned above, this was fixed on tip (current HEAD) of repo.
It wasn't closed based on the other comment.

[maxb]

Ah, thank you for clarifying.

Is there any more information available on what caused the unexpected downgrades?

[AlexanderYastrebov]

I observed the same problem while updating https://github.com/AlexanderYastrebov/noleak that itself has no dependencies:

$ go version
go version go1.20.5 linux/amd64

$ go get github.com/AlexanderYastrebov/noleak@latest
go: downgraded ...
...

and I can confirm that tip does not downgrade but I could not figure out a specific fix commit from the git log.