Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
When a module proxy returns an error, the go command shows only the HTTP status code.
In many cases the proxy will have more detail to report from the output of
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.
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.
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
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:
than a generic "we think upstream is broken" error that provides no further detail for debugging.
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.
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
This would be handy addition indeed.
For instance, we have a local go modules proxy at my job where it serves from
A user needs to set up gitlab token in order to have an access to gitlab repository:
And it would be nice to see sensible error output in this case in go get output: lack of token, invalid token, etc.
I guess this would work:
If go modules proxy response complies all these points
then go get will print that
I can understand if the full solution might be too risky, but I wonder if there is some simpler type of solution, or at least mitigation?
Here is a sample error message:
Right now, I think that contains the error-causing uri? However, it doesn't suggest visiting there, and that line doesn't say "error", and the key message is often nestled between other messages such that people don't always focus on the most pertinent line or otherwise recognize it as the real error.
Also, is there something in the release notes currently on how to troubleshoot a proxy error?
I don't quite have a handle on what classes of errors people are likely to see, but it seems there might be problems that have better errors if running with GOPROXY=direct, but then another class of problems that only occur when using the proxy and hence don't occur when running with GOPROXY=direct.
(We got a lot of reports of proxy-related confusion from users who had explicitly set
The signature of parseMetaGoImports implies that it can return an error, but it has not done so since CL 119675. Restore the missing error check, and remove the named return-values to avoid reintroducing this bug in the future. Updates #30748 Updates #21291 Change-Id: Iab19ade5b1c23c282f3c385a55ed277465526515 Reviewed-on: https://go-review.googlesource.com/c/go/+/189778 Run-TryBot: Bryan C. Mills <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Jay Conrod <firstname.lastname@example.org>
…leError VersionError wraps the given error in a ModuleError struct. If the given error is already a ModuleError for the same path and version, we now return it directly instead of wrapping. This makes it safer to call VersionError if we don't know whether a given error is already wrapped. Updates #30748 Change-Id: I41b23f6c3ead0ec382e848696da51f478da1ad35 Reviewed-on: https://go-review.googlesource.com/c/go/+/189781 Run-TryBot: Bryan C. Mills <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Jay Conrod <email@example.com>
Jay suggested this in CL 189780, and it seems semantically correct. As far as I can tell this has no impact one way or the other right now, but might prevent confusion (or at least give us more experience with error handling!) in future changes. Updates #30748 Updates #28459 Updates #30322 Change-Id: I5d7e9a08ea141628ed6a8fd03c62d0d3c2edf2bb Reviewed-on: https://go-review.googlesource.com/c/go/+/194817 Run-TryBot: Bryan C. Mills <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Jay Conrod <firstname.lastname@example.org>