Tyk newbies building a response plugin.
We’re seeing this error in the log (below).
Tried with renamed plugin binary, no difference.
Deleting the plugin conf stops these messages.
Appreciate any pointers. Thanks!
Log messages:
level=warning msg=“plugin file /opt/tyk-gateway/plugins/webhook_plugin_v5.7.1_linux_amd64.so doesn’t exist”
level=warning msg=“plugin file /opt/tyk-gateway/plugins/webhook_plugin_5.7.1_linux_amd64.so doesn’t exist”
level=error msg=“Could not load Go-plugin” error=“could not cast function symbol to http.HandlerFunc” mwPath=/opt/tyk-gateway/plugins/webhook_plugin.so mwSymbolName=WebhookPlugin
Version detail:
Release version: 5.7.1
Built by: goreleaser
Build date: 2024-12-29T22:36:34Z
Commit: d33f9f10f1a2f265240ca4fa34c07159dcfbf813
Go version: go1.22.10
OS/Arch: linux/amd64
Plugin binary:
linuxuser@tykhost01:/opt/tyk-gateway$ pwd
/opt/tyk-gateway
linuxuser@tykhost01:/opt/tyk-gateway$ ls -l plugins
total 12124
-rwxrwxrwx 1 root root 12412296 Jan 26 09:23 webhook_plugin.so
linuxuser@tykhost01:/opt/tyk-gateway$
Firstly I want to explain how the plugin naming works.
When you configure your API with a plugin file path like /opt/tyk-gateway/plugins/webhook_plugin.so the gateway automatically appends the gateway version, the OS and the CPU architecture and looks for that file. The nice thing about this is that when you upgrade to a new gateway version it doesn’t try to load the wrong build of your plugin since the version will have changed.
So in the API definition you should do as you’ve done and set the path to /opt/tyk-gateway/plugins/webhook_plugin.so but on the file system it should be called /opt/tyk-gateway/plugins/webhook_plugin_v5.7.1_linux_amd64.so. The plugin compiler should produce plugins named like that anyway.
That hasn’t got anything to do with the error message though, which is something else, although at the moment I don’t know what.
We’ve seen that error before, but only when someone tried to load a plugin into a slot that wasn’t yet supported. The post slot is most certainly supported and I’ve just built and deployed a post plugin on 5.7.1 to make sure there’s no issue.
Could you tell us how the plugin was built? The exact commands please.
I took your suggestion and changed the actual filename to webhook_plugin_v5.7.1_linux_amd64.so
All the other config remains the same i.e. the plugin conf still uses “webhook_plugin.so” etc.
The new log messages are below. My build call and go.mod contents are included. I’m building directly on my host, not docker, btw.
As a newbie, I’m clearly missing something very obvious. I’ve reviewed the documentation a few times but haven’t managed to find the exact needle in the haystack.
One additional thing - you mentioned slots. The only information I could find re slots appears to pertain to sharding. We’re definitely not doing that right now. Could you help me understand what slots means in this context?
Build call:
go build -trimpath -buildmode=plugin -v -o ./webhook_plugin.so webhook_plugin.go
go.mod:
module webhook_plugin
go 1.22.10
Log message:
level=error msg=“Could not load Go-plugin” error=“could not cast function symbol to http.HandlerFunc” mwPath=/opt/tyk-gateway/plugins/webhook_plugin.so mwSymbolName=WebhookPlugin
level=debug msg=Init api_id=1 api_name=helloget mw=“GoPluginMiddleware: /opt/tyk-gateway/plugins/webhook_plugin_v5.7.1_linux_amd64.so:WebhookPlugin” org_id=1
I’m building directly on my host, not docker, btw.
I’m afraid that’s not a supported method and will be very difficult to make work. Golang is very particular about plugins so we produce the plugin compiler docker image to ensure that it is exactly right. This is a golang restriction rather than a Tyk on. Please verify that the plugin compiler creates a usable shared object file to provide that it’s not an underlying issue in the product. Then if needed you can try to work out how to use a local compiler. Using a local compiler will be a difficult task though.
Yeah, I’m sorry I don’t have a better term. What I’m calling slots are the pre/post/post-auth/response plugin hooks spots as documented here. For example the response plugin was introduced in Tyk 3 (from memory) but a customer who was using Tyk 2 tried to use one and got the error could not cast function symbol to http.HandlerFunc.
I don’t think that is your issue though, I think it is most likely something to do with compiling the plugin.