Thank you for reporting this issue @rekby!

I am not sure what we can do here since the previous tag no longer exists upstream on the repository, meanwhile your go.mod/go.sum files contain the old checksums, thus you've declared that you want the non-existent commit to be built. This can happen in cases such as if someone
nefariously rewrites a commit and pushes up, so that error that you got is a safeguard.
Perhaps you should run go mod tidy on it to get back the old commit along with a go get -u?

However, I shall kindly loop in some go mod experts @bcmills @jayconrod.

When commit have no tag - go.sum contains part of commit hash - and it allow to computer find commit independent of tags.
Tags - more readable label for human and if go.sum contain tag - it is more readable, but lost accuracy - because the tag easy can rewrite by repo author and same tag point to other commit.

With commit it is more difficult - rewrite repo history and force push will change commit hashes in git and need full rebuild repo for svn.

I suggest add revision/commit hash to in additional to tag names, for example:

github.com/rekby-forks/test-mod v0.0.2(e9a220f8f3579aa9613bf755381b88f1fff60716) h1:ks22upaESPuYtz3t4FmkCKQCse5oMPs/gVTRavFVJlY=

it allow human read tag and human/computer read hash.

Then if tag point to different commit - go build can error with question what to do (change hash, change tag, stop) or fail with description with variants: change hash for use actual tagged version, change tag - for use previous commit.
Or it can show warning and use hash for checkout.

In any varian commit hash allow manual undestand what was previous state.
And prevent situation, when commit exist in repo, but no way to find it.

The go.mod and go.sum files are both written in terms of semantic versions, not commit hashes. That makes them — and the module proxy protocol — agnostic to the particular version-control system used to manage the code. (The commit hashes still leak through as pseudo-versions, but even then they're still represented as semantically-meaningful semver strings.)

The overall design of modules is that versions are immutable. A given version of a given module must always refer to the exact same contents. (The checksum database, for which support was added in Go 1.13, helps to ensure that property.) For that reason, we explicitly do not support changing semantic-version tags to point to different contents over time — if you need to tag a new release, it should have a new version number.

If you are worried about particular versions of your module dependencies disappearing or being deleted, one mitigation is to use a durable module mirror instead of fetching directly from upstream version control.

@rekby, did you encounter this problem in the wild, or is this concern mostly theoretical?

We've tried to communicate clearly that module versions must be immutable, but perhaps there are some loose ends in the documentation that we can clear up if we can figure out the source of confusion.

@bcmills it is mote theoretical problem - about repo owner.

For example I can change some tags in my small popular (near private) repo some times for ьн сщтмутшутсу if I think about only I use it. Or if I typo in tag (for example set tag v0.2 instead of v0.0.2). If I mistake and somebody add my repo from error tag v0.2 in short time, what tag existed - it can be problem for code consumer.

I did not encounded the problem in real wild.

You may safely change the tags on your repository as long as you are certain that nobody — including sum.golang.org — has fetched those tags yet.

If you accidentally typo a tag, such as v0.2.1 instead of v0.1.2, then the most robust way to fix it is to select and publish a higher version still.

I don't think there's anything more to be done about this. The entire purpose of the go.sum file and checksum database is to enforce that the mapping of versions to source code does not change over time.