cc @katiehockman @heschi @hyangah

Isn't the whole point of the proxy to keep serving things that have been deleted?

For tags and semver versions, I definitely agree. For branch names, I'm not that convinced. A branch is a moving target by definition.

An alternative would be to build special knowledge that, if master has vanished but main still exists, then /@v/master.info should redirect to /@v/main.info. I believe sites like proxy.golang.org and pkg.go.dev already treat master/main branches in a special way, so perhaps this extra rule would be reasonable. Intuitively, I think I'd prefer a fix that doesn't depend on branch names.

My personal preference (not go proxy or go command teams' opinion) is not to proxy or cache any version query string (e.g. tags, commit hash, branch name), and let proxy.golang.org just return 404/410 with a long TTL for such queries. I'd also like the go command to just automatically switch to direct mode (if GOPROXY includes it) for tags/branch names - my reasoning is that they are VCS-specific and it's better to let VCS handle. But tags such as `vX.Y.Z' which look like a version string that looks like go's recognized semver, but may be resolved to something else.

For tags and semver versions, I definitely agree. For branch names, I'm not that convinced. A branch is a moving target by definition.

This argument could be made if the repository is deleted as well. If the entire repository was deleted should sqlc@master return anything? I think @hyangah argument is more consistent.

I'd also like the go command to just automatically switch to direct mode (if GOPROXY includes it) for tags/branch names

I don't think the go command should automatically switch to direct mode for branch names or non-semver tags — the default proxy behavior is designed so that the proxy can explicitly reject, say, module paths that are known not to comply with the proxy owner's third-party-dependency policies.

(But I do agree that it would be fine for proxy.golang.org in particular to serve 404s or 410s for branches and non-semver tags, since it has no such policy to enforce.)

It may also be possible to change cmd/go to more clearly indicate the situation when a module's repository exists but the requested version (or nested module) is not present in that repository. The proxy could use that as an explicit signal to evict the cache entry.

This argument could be made if the repository is deleted as well.

Coming to this over two years later, but: the proxy should continue serving semver versions practically forever, unless there's something serious like a takedown notice or licensing issue. Otherwise, one pillar of reproducible builds falls down. I still think that branch names do not fall under that category, because they're not used by MVS nor commands like go build on a tidied module, as those don't need to resolve branches. It's only direct calls by humans or scripts like go install pkg@master which are affected.

I personally don't mind whether this detection of "branch deleted" happens in the proxy or in cmd/go. Intuitively, I would assume that the proxy can do it more efficiently, as it already needs to keep track of new versions published by the module, as well as cache some branch names. On the other hand, an implementation in cmd/go means that this would be solved for any proxy and not just proxy.golang.org.