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: go mod tidy -e should tolerate DNS resolution and network failures #53136

Open
oakad opened this issue May 29, 2022 · 6 comments
Open

cmd/go: go mod tidy -e should tolerate DNS resolution and network failures #53136

oakad opened this issue May 29, 2022 · 6 comments
Labels
GoCommand help wanted modules NeedsInvestigation WaitingForInfo
Milestone

Comments

@oakad
Copy link

@oakad oakad commented May 29, 2022

go version go1.18.2 linux/amd64

go mod tidy -e should do whatever tidying it can while ignoring errors and it indeed does it quite well. Unfortunately, when some remote host can not be resolved (either directly or by module proxy), it fails hard, as following:

go: finding module for package funny.host.com/some/unavailable/package
funny.host.com/some/other/package imports
funny.host.com/some/unavailable/package: cannot find module providing package funny.host.com/some/unavailable/package: unrecognized import path "funny.host.com/some/unavailable/package": https fetch: Get "https://funny.host.com/some/unavailable/package?go-get=1": dial tcp: lookup funny.host.com: no such host

I believe that it should not fail hard, but rather treat the network/DNS error as "skippable", in line with all the other possible errors.

For example, in my particular case, the missing packages are not really missing - they belong to the same project, but need to be generated (things like protobuf schema and such). Yet, I cannot tidy the rest of the project without making the remote git repo somehow available.

@dmitshur dmitshur added NeedsInvestigation GoCommand labels May 30, 2022
@dmitshur dmitshur added this to the Backlog milestone May 30, 2022
@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented May 30, 2022

CC @bcmills, @matloob.

@bcmills bcmills added the modules label Jun 1, 2022
@bcmills
Copy link
Member

@bcmills bcmills commented Jun 1, 2022

I agree that in principle the -e flag should push past these kinds of errors, although it might take a fair bit of debugging to figure out exactly where the error is not being propagated correctly.

@HowJMay
Copy link
Contributor

@HowJMay HowJMay commented Jun 3, 2022

let me try it!

@HowJMay
Copy link
Contributor

@HowJMay HowJMay commented Jun 14, 2022

Hi @oakad ! I have a question, after investigating the codebase. I found the exit code is 0 under the provided situation. May I ask the expected behavior in more detailed?

@oakad
Copy link
Author

@oakad oakad commented Jun 15, 2022

I have tested this myself and it's not quite conclusive; it is possible it was some sort of glitch on my side.

Or, may be the error which slips through is not of trivial nature, and happens somewhere between network failure, dns failure or sum db error response. But then, it may not be worth the time to hunt it down.

@bcmills bcmills added the WaitingForInfo label Jun 15, 2022
@bcmills
Copy link
Member

@bcmills bcmills commented Jun 15, 2022

Sounds like we need to figure out how to actually reproduce these errors. (If we can find a way to at least identify the root cause, then I agree that we should fix them, but I agree that it might not be worth spending a lot of time hunting it down.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand help wanted modules NeedsInvestigation WaitingForInfo
Projects
None yet
Development

No branches or pull requests

4 participants