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

cmd/go: should show error detail from module proxies #30748

Open
heschik opened this Issue Mar 11, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@heschik
Copy link
Contributor

heschik commented Mar 11, 2019

When a module proxy returns an error, the go command shows only the HTTP status code.

go get golang.org/x/net@latest: unexpected status (https://<proxy url>/golang.org/x/net/@v/list): 404 Not Found

In many cases the proxy will have more detail to report from the output of go mod download or go list. Proxy users should be able to see that; without it it's very hard to tell if the proxy is broken or if the user made a mistake.

One suggestion was simply to add the response body to the error message if it's text/plain. Maybe there should be some rules about it being one line, or maybe proxy authors should just use their judgement.

@bcmills @jayconrod @marwan-at-work @rsc

@bcmills bcmills added this to the Go1.13 milestone Mar 11, 2019

@marwan-at-work

This comment has been minimized.

Copy link
Contributor

marwan-at-work commented Mar 11, 2019

If cmd/go shows the status, then the Proxy can define what each status means.

For example, 404 means module not found while 400 means incorrect version etc.
If you want more details about an error, you can look at the GOPROXY server logs.

That said, I wouldn't mind it if Go exposed the response body, for pure debugging purposes although it might clutter the Go command output (maybe only behind -v, or maybe not)

@heschik

This comment has been minimized.

Copy link
Contributor Author

heschik commented Mar 11, 2019

That assumes that the go command can give very precise causes for an error, and even then I don't think it'd be enough. The reason I remembered to file this bug today is because Gerrit was having trouble on Friday. I think users are best served by an error more like the one they'd have seen going direct to the VCS:

git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in .../pkg/mod/cache/vcs/4a22365141bc4eea5d5ac4a1395e653f2669485db75ef119e7bbec8e19b12a21: exit status 128:
        fatal: remote error: Internal Server Error

than a generic "we think upstream is broken" error that provides no further detail for debugging.

you can look at the GOPROXY server logs

If you have access and know where to look, sure. But in a sufficiently large organization, or for a user of a central proxy service, that's not so easy.

@marwan-at-work

This comment has been minimized.

Copy link
Contributor

marwan-at-work commented Mar 11, 2019

That assumes that the go command can give very precise causes for an error, and even then I don't think it'd be enough

It's not the go command that gives the error code, it's the GOPROXY that returns a status code and the go command outputs it for the client (you). Therefore, if you know what those error codes mean on the proxy side, then you should be able to understand what they mean.

That said, it'd be nice to add the response body potentially behind a -v flag or some rule that doesn't clutter the go build too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.