Structs and context keys corrupt when vendoring dependencies

[mcandre]

What version of Go are you using (go version)?

$ go version
go version go1.14 darwin/amd64

Does this issue reproduce with the latest release?

Not sure.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/pen4587/Library/Caches/go-build"
GOENV="/Users/pen4587/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/pen4587/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/pen4587/.gvm/gos/go1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/pen4587/.gvm/gos/go1.14/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/7p/fn0jqw_s0cq5sc9z3dc64n5h0000gp/T/go-build231196558=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

1. Added github.com/TykTechnologies/tyk as a git submodule in vendor/github.com/TykTechnologies/tyk.
2. Checked out the exact same commit in the git submodule as the Tyk binary I am using.
3. Build my Tyk plugin.
4. Load my Tyk plugin.
5. Query HTTP request context info for the metadata that Tyk provides to plugins.
6. Dump this HTTP request context info to stdout.

What did you expect to see?

A Tyk API definition.

What did you see instead?

The context value is uncastable.

The context key produces a nil value.

I tried Go 1.12, 1.13, and 1.14 with no apparent change in behavior.

I replaced the git submodule with a direct cp -r from the $GOPATH/src/... to vendor/..., with no change in behavior.

I tried all the available GO111MODULE values, with largely no effect. Other than flat out breaking compilation when set to on.

Making sure to use the same environment variables, build flags, host OS for both the Tyk binary and the Tyk plugin.

Workaround

For now, the only way I can consistently work around this struct and iota context key corruption, is to stop vendor/ing my library dependency, and manage the dependency with pure go get... in $GOPATH/src

It's almost as if Go earmarks vendored dependencies differently in the namespace / type system, when comparing Context keys and when casting generic interface{}'s to a more specific type.

[mcandre]

Specifically, this problem:

#27062 (comment)

[bcmills]

I tried all the available GO111MODULE values, with largely no effect. Other than flat out breaking compilation when set to on.

That's the thing to fix, though.

It's almost as if Go earmarks vendored dependencies differently in the namespace / type system, when comparing Context keys and when casting generic interface{}'s to a more specific type.

In GOPATH mode, the go command treats each vendored copy of a package as a distinct package with its own identity, so the types and values defined in those packages (including when used as context keys) are also distinct.

That is one of the problems that module mode was designed to fix, so the fix here is “use module mode”.

(There may be other issues in using module mode, but if so we should fix those issues — please file them separately. Module mode is the fix for the bad vendor behavior in GOPATH mode.)

[bcmills]

Duplicate of #30838