go: sum.golang.org: responding with a 410 fifteen minutes after publishing a new module version
$ go version
go version devel +f7a80af935 Mon Nov 23 05:47:51 2020 +0000 linux/amd64
$ go get -d github.com/multiformats/go-multicodec@v0.2.0
github.com/multiformats/go-multicodec@v0.2.0: verifying module: github.com/multiformats/go-multicodec@v0.2.0: reading https://sum.golang.org/lookup/github.com/multiformats/go-multicodec@v0.2.0: 410 Gone
server response: not found: github.com/multiformats/go-multicodec@v0.2.0: invalid version: unknown revision v0.2.0
$ GONOSUMDB='*' go get -d github.com/multiformats/go-multicodec@v0.2.0
$ GOPROXY=direct GONOSUMDB='*' go get -v -d github.com/multiformats/go-multicodec@v0.2.0
At the time of running these commands, I pushed the new version via git tag -a v0.2.0 && git push --tags over fifteen minutes ago. Why am I still getting a 410?
Note how skipping sum.golang.org alone, or skipping both the sumdb and proxy, make the go get work. These commands were run outside of any module.
At first I assumed I was holding something wrong, but I’ve triple-checked everything. You can see the version at https://github.com/multiformats/go-multicodec/blob/v0.2.0/go.mod. I realise that the tag says “five hours ago”, because that’s when I tagged it - but I only pushed the tag fifteen minutes ago.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 13
- Comments: 22 (17 by maintainers)
I ran into this exact problem too:
go get -u github.com/matthewmueller/some-packagego get -u github.com/matthewmueller/some-package@v0.12.9It took me some trial and error to figure out what was going on. Sharing my usage report in case it’s helpful. It’s starts with the error. The error unfortunately doesn’t guide you towards the answer:
Googling around is difficult because the
unknown revisionerror seems to happen most often on private modules. There it instructs you to mess with your git config and whatnot. I published a public package so these instructions didn’t make sense.Without much luck, I flailed around a bit:
Finally on a whim, I tried disabling go sum:
That did the trick. It now works as if nothing was ever wrong.
Is there any update on this? It doesn’t happen very often, but when it happens, having to wait for the cache entry to expire is such a productivity killer, especially if one is bubbling up changes through a chain of dependencies.
Thanks for your quick response.
I think closing this issue on the technicality that the cache isn’t buggy is a mistake. The cache is an implementation detail that I shouldn’t need to worry about, in general. The steps I shared above are pretty common, I think - that is, doing the first
go getjust a second too early, before the version is picked up by the proxy. And the experience is pretty frustrating - the services keep telling me that no such version exists, and all I can see on the website FAQ is:So, it’s clearly been longer than a minute, hence I file the bug.
At the very least, if the confusing UX is here to stay, I certainly believe it should be clearly documented. Because, right now, the “after one minute” goes directly against my experience of seeing nothing for over half an hour.
Someone at work points out that this is because I did a
go get -d github.com/multiformats/go-multicodec@v0.2.0before the tag had been picked up by the proxy, so sum.golang.org must have cached the “version does not exist” proxy answer for 30m without trying again for a while. This seems to be confirmed by how, all of a sudden,go getworks and it’s roughly been 35 minutes since the tag was pushed.Regardless of whether this is expected behavior, it seems fairly counter-intuitive and frustrating to the end user. Perhaps the proxy and sumdb should be taught to invalidate such a cached state when a new version is published.
I’ve run into this problem so many times, so first of all, I’d like to thank @mvdan for raising this issue. It’s been really annoying to have to wait for half an hour just to bubble up a version update, so my - not very sophisticated - workaround has been to wait for at least 5 minutes before go getting a new version I just released.
Keeping a stale cache entry for half an hour seems like a bad solution in general. Reducing that time to one minute wouldn’t be a bad resolution of this issue. Even better would be reducing it to a few seconds with exponential backoff afterwards, but I’m not sure how much overhead that be in the cache implementation.
Yep, it looks clear now, thanks! Personally I’d hope to see that 30-minute worst case scenario be a shorter delay, but I get that it’s not an easy tradeoff 😃
That’s fair, thanks for making this point about the docs. At a minimum, it may make sense for the documentation to be updated to more clearly state expectations. I’ll re-open this so that we can determine the right course of action on this.
See also https://github.com/golang/go/issues/41986
410 seems a strong response to give for a tag that has never been seen by the sum server since clients are free to interpret that as a permanent status. 404 would more appropriate for unknown tags, leaving 410 for retracted ones.