Go build failure: "Downloaded inconsistent tile" when running "go build" with go mod file

Question

I'm just starting a project and want to use go modules. I've created a new repo with a small amount of functionality, but it refuses to build. I have tested go build without modules and it works just fine. Error message:

C:\Users\gledr\Polyapp_Apps\gocode\src\gitlab.com\polyapp\go-wasm-mvc>go build go: extracting github.com/rs/cors v1.7.0 verifying github.com/rs/cors@v1.7.0: github.com/rs/cors@v1.7.0: initializing sumweb.Conn: checking tree#187855: downloaded inconsistent tile

What does this error mean?

I assume this error means I must re-download the relevant package, even though the package works without go modules??

Notes about my project

• Standard library imports work as expected
• Zero non-standard library imports seem to work
• go build works great if I delete go.mod but fails with go mod init go build
• You can clone the project here: https://gitlab.com/polyapp-open-source/go-wasm-mvc (obviously I haven't written a single feature yet...)
• You can also go get gitlab.com/polyapp-open-source/go-wasm-mvc the project

Attempts to resolve the problem

• No similar Stack Overflow questions ("downloaded inconsistent tile" only has 2 google results for me)
• The code throwing the error is here: https://github.com/golang/mod/blob/master/sumdb/tlog/tile.go
• Based on the code throwing the error, it seems I must delete the failed download (even though it works without go mod??.). I did so, I deleted the relevant folder in $GOPATH/pkg under several sub-directories and I deleted the source in $GOPATH/src but when I do this, it still throws the error
• I tried using go build -d github.com/blahblahblah to get the files re-downloaded, but it apparently did absolutely nothing
• This check may exist because of the go sum proposal for 1.13 seen here (ctrl+f for "inconsis"): https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md
• If you read the go sum proposal above, it says "No go command (only a manual rm -rf $GOPATH/pkg ) will wipe out the memory of the latest observed tree size and hash". I believe this is the situation I am in, but when I removed the subpackage in the $GOPATH it still fails.
• In the spirit of saving my $GOPATH/pkg folder, I tried deleting the cache here: $GOPATH/pkg/mod/cache/download/github.com/[package name] but oddly although deleting the cache triggered a new 'go get', the re-downloaded file also had an inconsistent tile. From this experience I assume something is kooky with the go sum <-> $GOPATH/pkg verification.

go env

set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\gledr\AppData\Local\go-build
set GOENV=C:\Users\gledr\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\gledr\Polyapp_Apps\gocode
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\gledr\Polyapp_Apps\gocode\src\gitlab.com\polyapp\go-wasm-mvc\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\gledr\AppData\Local\Temp\go-build525753618=/tmp/go-
build -gno-record-gcc-switches```

Answer 1

I ended up renaming the $GOPATH/pkg directory to $GOPATH/old_pkg - the equivalent of rm -rf $GOPATH/pkg as suggested in the Go SUM proposal I linked in the question. Therefore all of the dependencies had to be re-downloaded, but it does work now.

Deleting the $GOPATH/pkg folder also resulted in another, much larger project of mine starting to work. It just took a few minutes to re-download all of the dependencies.

Answer 2

try to run command: go clean --modcache

Answer 3

The error means a difference between the actual checksum versus available checksum from checksum DB. Pulling in dependencies from a single place will help but based on the case that was described, there was a dependency change on your end even though the version of dependencies is constant.

Did you recently move to Go 1.13? Or were you using a different GOPROXY before?