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.

Sign up for GitHub

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

Jump to bottom

cmd/go: go get of nested module picks version from outer module #61237

Closed
twmb opened this issue Jul 8, 2023 · 4 comments
Closed

cmd/go: go get of nested module picks version from outer module #61237

twmb opened this issue Jul 8, 2023 · 4 comments
Labels
GoCommand cmd/go modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@twmb
Copy link
Contributor

twmb commented Jul 8, 2023

This is a continuation of #56974, which was closed due to being stale and I cannot reopen.

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/twmb/franz-go/pkg/kadm@v1.6.0

Screenshot

Screenshot 2022-11-28 at 10 53 16 PM

What did you do?

I have a repo, github.com/twmb/franz-go with a module at the top-level repo root and other modules at subdirectories. Whenever I release the repo root (push a tag), I can go get -u the new version of the project within seconds. When I release a sub-module, it takes more time -- and if I release the main module quickly followed by a submodule, it takes tens of minutes (I'm not sure when / if the cache will purge).

Repo structure:

github.com/twmb/franz-go/go.mod
github.com/twmb/franz-go/pkg/kadm/go.mod
...

I've managed tags like this for over a year now, and the wait for submodules has never been this long.

What did you expect to see?

go get github.com/twmb/franz-go/pkg/kadm@v1.6.0 to not fail for 30 minutes.

What did you see instead?

$ go get -u github.com/twmb/franz-go/pkg/kadm@v1.6.0
go: module github.com/twmb/franz-go@v1.6.0 found, but does not contain package github.com/twmb/franz-go/pkg/kadm

for 30 minutes

Now, this is happening again -- a separate submodule is also now at 1.6.0 (coincidentally the same as this original issue).

This is happening on v1.20.5.

I released a new module, github.com/twmb/franz-go/pkg/kmsg@v1.6.0.

$ go get -x github.com/twmb/franz-go/pkg/kmsg@v1.6.0
go: module github.com/twmb/franz-go@v1.6.0 found, but does not contain package github.com/twmb/franz-go/pkg/kmsg

The Go command does not issue any http requests. I suspect it's because I have old franz-go versions in my mod cache:

@m4x3r:~/go/pkg/mod/github.com/twmb
$ ll | grep franz
drwxr-xr-x travisbischel staff 128B Fri Mar 24 11:57:20 2023 franz-go/
dr-xr-xr-x travisbischel staff 480B Fri Mar 24 11:57:20 2023 franz-go@v1.11.5/
dr-xr-xr-x travisbischel staff 480B Sat Mar 25 10:23:19 2023 franz-go@v1.12.0/
dr-xr-xr-x travisbischel staff 480B Thu Apr 13 15:06:39 2023 franz-go@v1.12.1/
dr-xr-xr-x travisbischel staff 512B Fri Mar 24 12:27:20 2023 franz-go@v1.13.0/
dr-xr-xr-x travisbischel staff 512B Fri Mar 24 12:27:05 2023 franz-go@v1.13.1/
dr-xr-xr-x travisbischel staff 512B Fri Apr 14 13:21:41 2023 franz-go@v1.13.2/
dr-xr-xr-x travisbischel staff 512B Tue May  9 12:35:53 2023 franz-go@v1.13.3/
dr-xr-xr-x travisbischel staff 512B Tue May 30 11:32:44 2023 franz-go@v1.13.4/
dr-xr-xr-x travisbischel staff 512B Fri Jun  2 11:47:55 2023 franz-go@v1.13.5/
dr-xr-xr-x travisbischel staff 512B Wed Jul  5 23:57:52 2023 franz-go@v1.13.6/
dr-xr-xr-x travisbischel staff 480B Mon Apr 10 11:26:22 2023 franz-go@v1.2.3/
dr-xr-xr-x travisbischel staff 512B Mon Apr  3 21:59:03 2023 franz-go@v1.6.0/
dr-xr-xr-x travisbischel staff 512B Wed Apr  5 10:58:13 2023 franz-go@v1.7.1-0.20220901194750-0ca6478600c6/

So go sees franz-go@v1.6.0 exists, but because kmsg is a separate module, the pkg is not in that top-level module:

@m4x3r:~/go/pkg/mod/github.com/twmb/franz-go@v1.6.0/pkg
$ ll
dr-xr-xr-x travisbischel staff 128B Mon Apr  3 21:59:03 2023 kbin/
dr-xr-xr-x travisbischel staff  96B Mon Apr  3 21:59:03 2023 kerr/
dr-xr-xr-x travisbischel staff 1.1K Mon Apr  3 21:59:03 2023 kgo/
dr-xr-xr-x travisbischel staff 128B Mon Apr  3 21:59:03 2023 kversion/
dr-xr-xr-x travisbischel staff 224B Mon Apr  3 21:59:03 2023 sasl/

I suspect this is causing the failure we see.
@seankhliao seankhliao added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. GoCommand cmd/go modules labels Jul 8, 2023
@bcmills
Copy link
Contributor

bcmills commented Jul 10, 2023

@twmb, does this resolve on its own after some amount of time, or does it remain reproducible until some other change to your module cache occurs?

If it is purely time-based, then I suspect it is related to #38065.

@bcmills bcmills added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jul 10, 2023
@twmb
Copy link
Contributor Author

twmb commented Jul 10, 2023

@bcmills it resolved after time -- it took >20 minutes. I'm not sure when exactly things started working. I eventually noticed a problem with v1.6.0 and tagged v1.6.1 -- that also took >20 minutes to pick up, but the output from -x showed that the mod database was 404ing trying to get the tag (so it seemed like the 404 was cached for a long time as well). I eventually went to sleep and the next day, everything was resolved.

@seankhliao
Copy link
Member

Sounds like this is probably #38065

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Aug 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GoCommand cmd/go modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@twmb @bcmills @seankhliao and others