`outlinecaddy` nested module: `@latest` resolves to the parent's `v1.9.2` instead of the module's own version

[ohnorobo]

Summary

go get golang.getoutline.org/tunnel-server/outlinecaddy@latest resolves to v1.9.2 — a parent tunnel-server version — rather than the outlinecaddy nested module's own tag (v0.0.1). Consumers get a confusing/incorrect "latest."

Reproduce

GOPROXY=direct GOSUMDB=off go list -m -versions golang.getoutline.org/tunnel-server/outlinecaddy
#   -> v0.0.1                                  (the nested module's only tag)

go list -m golang.getoutline.org/tunnel-server/outlinecaddy@latest
#   -> ...outlinecaddy v1.9.2                  (WRONG: a parent tunnel-server version)

The public proxy's version list for the path even includes the full set of
parent v1.x tags:

curl https://proxy.golang.org/golang.getoutline.org/tunnel-server/outlinecaddy/@v/list

Root cause

outlinecaddy/ started as a package inside the parent module and was later promoted to its own nested module (outlinecaddy/go.mod, module path …/tunnel-server/outlinecaddy). Its only nested tag is outlinecaddy/v0.0.1. Because the import path was reachable in the parent module up through v1.9.2, those parent vX.Y.Z tags are still treated as versions of the path — and @latest prefers the highest release version, so v1.9.2 (1.9.2) wins over the nested v0.0.1.

For contrast, the sibling sdk/x nested module works correctly: its tags reach x/v0.2.0 while the parent sdk only reaches v0.0.23, so the nested version is the highest and @latest lands on it. outlinecaddy is the inverse — its nested version is below the parent's.

This is purely a tagging issue in this repo; the vanity-import setup (golang.getoutline.org) and hosting are correct.

Fix

Tag the nested module with a version greater than the parent's highest tag
(v1.9.2), e.g.:

# on the commit carrying the intended outlinecaddy/go.mod
git tag outlinecaddy/v1.9.3
git push origin outlinecaddy/v1.9.3

Then …/outlinecaddy@latest resolves to the nested module.

Alternatives: move outlinecaddy to its own repo, or bump it to v2.0.0+ —
note v2+ requires the /v2 major-version suffix in the module path and imports.

References (Go guidance)

• Module version tags for modules in a subdirectory must be prefixed
  subdir/vX.Y.Z:
  Go Modules Reference §Mapping versions to commits
• How @latest / version queries select a version:
  Go Modules Reference §Version queries
• Working with multiple modules in one repository:
  Managing module source and
  Module release workflow

[fortuna]

The diagnosis seems wrong. I think the vanity url may not be set up properly. We need to fix the serving of our vanity url. Stop manually specifying each module, and have a proper reverse proxy instead. Example: https://github.com/lukecarr/cf-go-vanity-imports

[jyyi1]

We encountered a very similar issue previously with the sdk/x nested module.

The root cause was that an incorrect vanity HTML configuration caused the Go proxy (gopkg) to crawl and cache the parent module's version tags. Since the parent module had a higher version number than the nested module, the proxy assumed the parent's version was the latest. Consequently, any subsequent versions of the nested module couldn't be correctly resolved using @latest because the proxy always preferred the cached, higher parent version.

For sdk/x, we resolved this with the following steps:

1. We ensured the vanity HTML for the sdk/x package was correctly configured (see sdk/x.html).
2. We retracted all the existing, affected versions in the sdk/x/go.mod.
3. We released a new version for the sdk/x (x/v0.1.0) that was strictly greater than all of the parent module's versions to force @latest to resolve correctly (see x/v0.1.0 release).

It is highly likely that outlinecaddy is facing the exact same issue: a misconfiguration led the proxy to cache the parent's v1.9.2 tag. To fix this, I recommend the similar approach:

1. Verify and update the vanity HTML for this sub-package so it functions correctly like sdk/x's HTML. (Note: The current tunnel-server/outlinecaddy.html still points to the old Jigsaw-Code repo instead of OutlineFoundation. While this specific URL mismatch isn't the main cause of the version clash, it definitely needs to be updated!)
2. Retract all existing broken versions in outlinecaddy/go.mod.
3. Release a new tag for the sub-package that is higher than the parent's highest version. This will ensure that gopkg successfully picks up the nested module's latest version moving forward.