Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Structs and context keys corrupt when vendoring dependencies #41556

Closed
mcandre opened this issue Sep 22, 2020 · 3 comments
Closed

Structs and context keys corrupt when vendoring dependencies #41556

mcandre opened this issue Sep 22, 2020 · 3 comments
Labels
FrozenDueToAge

Comments

@mcandre
Copy link

mcandre commented Sep 22, 2020 •
edited

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 mcandre mentioned this issue Sep 22, 2020
Closed
@mcandre
Copy link
Author

mcandre commented Sep 22, 2020

Specifically, this problem:

#27062 (comment)

@bcmills
Copy link
Contributor

bcmills commented Sep 22, 2020

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
Copy link
Contributor

bcmills commented Sep 22, 2020

Duplicate of #30838

@bcmills bcmills marked this as a duplicate of #30838 Sep 22, 2020
@bcmills bcmills closed this as completed Sep 22, 2020
@golang golang locked and limited conversation to collaborators Sep 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mcandre @bcmills @gopherbot