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: sometimes rate limits @master package refreshes beyond documented "one minute" #38507

Open
bradfitz opened this issue Apr 17, 2020 · 8 comments

Comments

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Apr 17, 2020

https://proxy.golang.org/ says:

After one minute for caches to expire, the go command will see that tagged version. If this doesn't work for you, please file an issue.

It's been minutes since I tagged a new version of inet.af/netaddr but it's not showing up:

$ go get inet.af/netaddr@v0.1
go get inet.af/netaddr@v0.1: no matching versions for query "v0.1"
$ go get inet.af/netaddr@0.1
go get inet.af/netaddr@0.1: inet.af/netaddr@0.1: invalid version: unknown revision 0.1
$ git ls-remote git@github.com:inetaf/netaddr
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        HEAD
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        refs/heads/master
...
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        refs/tags/v0.1

Am I holding it wrong?

https://godoc.org/inet.af/netaddr is updated at least. Its refresh is instant.

/cc @hyangah @heschik

@bradfitz
Copy link
Contributor Author

@bradfitz bradfitz commented Apr 17, 2020

GOPROXY=direct unblocked me, FWIW.

@hyangah
Copy link
Contributor

@hyangah hyangah commented Apr 17, 2020

I think this is a bug (or surprising behavior) of the go command when the version string looks like a version string but not the form of vX.Y.Z. @jayconrod @bcmills @matloob

Are you sure GOPROXY=direct unblocks you?

$ GOPROXY=direct GOPATH=`mktemp -d` go get inet.af/netaddr@1.0
go get inet.af/netaddr@1.0: inet.af/netaddr@1.0: invalid version: unknown revision 1.0

Can you tag it with v0.1.0?

@bradfitz
Copy link
Contributor Author

@bradfitz bradfitz commented Apr 17, 2020

I only tried tagging it because my normal go get foo@master or go get foo@latest weren't updating my go.mod any more so I figured creating a tag might un-rate-limit me and finally refresh.

What actually unblocked me was GOPROXY=direct go get ...@master which updated my go.mod. Then 10-15 minutes later coworkers were able to fetch that revision from the proxy.

So just seems like I or the module was being rate-limited for refreshes. (Can you document that more without telling attackers specific thresholds?)

But good to know that tags need to be totally semver and not have implicit .0 suffixes for the remaining part. I've been corrupted by Go version numbers apparently.

@hyangah
Copy link
Contributor

@hyangah hyangah commented Apr 17, 2020

For pseudo-versions or non-version/branch tags, I agree the user experience is not great.
A tip: when working with a repo that updates frequently or working on a dev/master branch, use of GONOPROXY or GOPRIVATE env vars worked well for me (Or permanently setting with go env -w)

Documentation needs to be improved. @katiehockman @heschik

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 18, 2020

go get inet.af/netaddr@v0.1 is a version prefix query for the latest version tagged v0.1.*; that's why the failure message changes to no matching versions.

@bradfitz bradfitz changed the title proxy.golang.org: inet.af/netaddr tag not showing up proxy.golang.org: sometimes rate limits @master package refreshes beyond documented "one minute" Apr 18, 2020
@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Apr 20, 2020

#29731 is an issue about changing queries like @v0.1 to fall back to branches or tags.

In this situation though, it would still give a pseudo-version, which is probably not what you want.

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 20, 2020

In theory we could resolve prefix tags to prefix-derived pseudo-versions (the same that we do for +metadata suffixes) but I think that would probably add more confusion than it resolves.

@bradfitz
Copy link
Contributor Author

@bradfitz bradfitz commented Apr 20, 2020

To be clear, I don't really care about the v0.1 not working part. That was just my mistake while in an act of desperation trying to kick the machinery into polling again.

What I really cared about was that I was working between two repos and couldn't make forward progress in repo A because it depended on repo B and proxy.golang.org wasn't re-polling B. GOPROXY=direct fixed it for me locally, but had I pushed my go.mod, it would've broken others unless they too were using GOPROXY=direct.

So my workflow was interrupted and I just had to wait until some mysterious process elsewhere un-ratelimited me. (hence me running off and reading proxy.golang.org docs, seeing "one minute" and filing this bug)

@andybons andybons added this to the Unplanned milestone Apr 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.