Go Plugin not loading for version 5.3.2

Support Administration and Operation
, ,
1

Hi everyone,

I’m currently using Tyk Gateway v5.3.2 and have encountered an issue while trying to load a custom Go plugin during container startup. I’m using the plugin [email protected] to build my plugins, so everything should be in sync in terms of versions.

However, when I start the Tyk container, I receive the following error:

2024-10-03 16:39:20 time="Oct 03 13:39:20" level=error msg="Could not load Go-plugin" error="plugin.Open(\"/opt/tyk-gateway/middleware/edge_authentication/mw_edge_authentication_v5.3.2_linux_amd64\"): plugin was built with a different version of package internal/godebugs" mwPath=/opt/tyk-gateway/middleware/edge_authentication/mw_edge_authentication mwSymbolName=AuthenticateDevice

It seems like the error points to a version mismatch, specifically with the Go package internal/godebugs. From what I understand, this happens when there is a mismatch between the Go versions used for building the plugin and running Tyk, but I’m sure that both the Gateway and the plugin were built using the same version (v5.3.2).

What I’ve Tried:

• Verified that the Tyk version and the plugin compiler version are both v5.3.2
• Rebuilt the plugin to ensure it’s using the correct Go version that matches Tyk’s runtime
• Checked that the plugin is copied properly to the container and it’s named accordingly

In my go.mod i set the go version to 1.21.0, which AFAIK is the version that plugins should be built with. Before building the image, i ran go mod tidy.

Has anyone else run into a similar issue? Are there any additional steps I might be missing to ensure plugin compatibility?

Any help or suggestions would be greatly appreciated!

Thanks in advance for your help!

1 Like
2

This is a golang limitation rather than a Tyk one however an experienced golang developer will probably have the expertise to work around it.

The reason it’s happening is because you are using another package that is pulling a different version of internal/godebugs which conflicts with the version that Tyk was built with.

There is a topic that refers to a similar issue

I once saw a suggestion where you could fork the package causing the conflict and give it a go.mod that uses the Tyk compatible versions. However, I am unaware of the results

You may have to check the output of the compile to find the package adding the conflict

You could just let the plugin compiler to the go tidy and go get commands internally. You can find more here

3

Thanks for the quick reply!

I have tried the last solution you provided, i.e. letting the compiler run the go get and go tidy commands, as described in the linked post. Here’s the commands I ran

rm go.mod go.sum
docker container run -v `pwd`:/plugin-source -t --workdir /plugin-source --entrypoint go --rm tykio/tyk-plugin-compiler:v5.3.2 mod init  mw_edge_authentication.so

docker container run -v `pwd`:/plugin-source --env GO_TIDY=1 --env GO_GET=1 --rm tykio/tyk-plugin-compiler:v5.3.2 mw_edge_authentication.so $(date +%s%N)

Unfortunately, this didn’t solve my issue and I’m still getting an error about conflicts with internal/godebugs.

Just as a note: I tried version 5.2.2 which worked perfectly. I’m not exactly sure what has changed between these 2 versions.

4

What’s your OS?

The quickest thing I can find is Plugin compiler

  • since 5.2.4: the plugin compiler adjusts the Go module in use for the plugin.

But their go versions are most likely different.

Maybe our plugin debugging docs could help (but please note it’s still WIP, open to feedback)

5

I’m on a M1 mac with Sonoma 14

6

I know there are some CPU architecture compiling issues for M1 as the gateway image needs to be forced to be linux/amd64 

time="Mar 29 17:22:28" level=error msg="Could not load Go-plugin" error="plugin.Open("plugins/go/example/example-go-plugin.so"):
/opt/tyk-gateway/plugins/go/example/example-go-plugin.so: cannot open shared object file: No such file or directory"
mwPath="plugins/go/example/example-go-plugin.so" mwSymbolName=AddHelloWorldHeader

But I don’t think that applies here

Have you had the chance to try the plugin debugging docs? I think I remember a similar error message thrown when the hash of the gateway version did not match.

Running go version -m on the plugin binary and gateway release while comparing their outputs should reveal their differences.

7

Yeah, I don’t think this really applies. I’ve ran export DOCKER_DEFAULT_PLATFORM=linux/amd64 to make sure the images are being built correctly. I’ve had this problem of plugins not loading because of this in the past, but this fixed it.

I’ve gone through the plugin docs and this is the output for running go version -m <plugin>.so:

        build   -buildmode=plugin
        build   -compiler=gc
        build   -trimpath=true
        build   CGO_ENABLED=1
        build   GOARCH=amd64
        build   GOOS=linux
        build   GOAMD64=v1

As the tyk image, I’m using v5.3.2 AMD64 from the docker hub. I’m not entirely sure how I can see the build values for it.

8

Hi @dgcirt ,

I am using the similar M1 version:

ProductName: macOS
ProductVersion: 14.2.1
BuildVersion: 23C71

And I follow below steps that you can try it or compare, may be it will help you to understand the flow:

Kind Regards,
Shebby

9

Hi everyone.
Thanks for the answers and sorry for circling back on this after so long.

We tried to make v5.3.2 work in our testing environment and unfortunately that failed as well – same error message as my local tests.

It doesn’t seem to me like this is a CPU architecture problem after all. As a solution, we decided to update to v5.4.0 to save ourselves the headache of debugging this further. The new version worked just fine. One note here is that looking through the go.mod file built for v.5.4.0 I’ve noticed the following:

  • go version for v5.4.0 is 1.21.11 while for v5.3.2 it is 1.21.12
  • the go.mod for v5.4.0 contains less depenencies than the other version

I used this commit id to get the working Tyk version: 9b62c317f33ab348704455610758324073d15a98

My decision, ultimately, is to run this working version until a new LTS will be available or something changes for v5.3.x that will solve this plugins issue.

Thanks for the time invested in this!

1 Like