I suspect in the general case this is working as intended. The Go 1.22 language isn't finalized yet, and in theory go env GOMOD in a Go 1.22 module may do something that today's go command doesn't know about and can only produce correct behavior by doing the download.

Does it work well to do go get go@go1.21 in said module before go env GOMOD if using Go 1.21 (RC 3 or so), or using a very recent gotip that knows how to work with a 1.22 module?

Edit: I see now that there's motivation to make a special exception for go env GOMOD. Never mind. :)

Yep, go env GOMOD and go env GOWORK in particular have to be valid (or at least somewhat sensible), because those are what we use to determine which toolchain to upgrade to.

I suppose it's possible that we upgrade the toolchain via the go.mod and/or go.work file that we find and then the reinvoked toolchain decides to do something else instead (perhaps based on an environment variable), but a change that affects that sequence seems unlikely in the foreseeable future.

Is this message helpful and actionable -

Just got bitten by this thing - the installed Go version is 1.21.7, the go.mod file has 1.22, and the CI script was trying to run go version to determine the installed Go version and see if it would need to be updated (and normally the new version of Go would be fetched and installed after that). The failure (quite cryptic, IMO) was:

go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

a workaround would be to cd /tmp before executing go version. Still seems unfortunate to have to do this...

@dmitris - I tried a fix for this with local installed go version correcting mod file. Screenshot was attached.

There is one more scenario..

Do you consider is it worth to get rid of manual version update on go workspace with go developement project shared with other go modules when ever a bump happens say 1.22 to 1.23.

For that , I am thinking of an approach is there a way to know - golang/go project do exist under workspace for respective go commands( advise user on that) and change to that version for workspace and correct other modules under that workspace if needed.

@matloob, @samthanawalla: this is a side-effect of the recent addition of toolchain-upgrade support. I think it will have a fairly straightforward fix.

@bcmills - I already did a fix. Shall I CL that ?

Just got bitten by this thing - the installed Go version is 1.21.7, the go.mod file has 1.22, and the CI script was trying to run go version to determine the installed Go version and see if it would need to be updated (and normally the new version of Go would be fetched and installed after that). The failure (quite cryptic, IMO) was:

go: downloading go1.22 (linux/amd64)
go: download go1.22 for linux/amd64: toolchain not available

@dmitris I think the error you're getting will be fixed with #66175
I think what's happening in your case is that go is trying to download the go1.22 toolchain which is not a valid toolchain.
go1.22.0 is a valid toolchain. We're changing the behavior so that it should automatically add a .0 in that case and download go1.22.0
Sorry for the frustration!

@prattmic
Regarding OP, just to confirm, the requested change is that we don't want go env GOMOD to download the newer toolchain? You only want it to display the file name of the go.mod file and not upgrade?

Regarding OP, just to confirm, the requested change is that we don't want go env GOMOD to download the newer toolchain? You only want it to display the file name of the go.mod file and not upgrade?

Yes, that was the original intention intended by this issue (Bryan suggested I file this issue). I don't personally feel strongly about the behavior, it is just a bit of an oddity given that cmd/go needs to find go.mod in order to upgrade in the first place.

Change https://go.dev/cl/581275 mentions this issue: cmd/go: go env GOMOD should not download newer toolchain