Debugging custom plugin utilizing tcp and preread

Questions
1

Hello!

Im working on a custom plugin that is working as expected when tested with Pongo, however, when I bring the plugin into a test cluster the “preread” function of the plugin does not get called.

To isolate testing as much as possible I reduced my plugin to barebones and verified that the plugin is loaded by placing an assert at the start of the handler.lua, but an assert placed in the preread function is not called.

I am inclined to believe what while the plugin is loaded its not part of the included plugins executed here:
https://github.com/Kong/kong/blob/2.1.3/kong/init.lua#L640. The confusing part of this is that the plugin (and the barebones version) both run correctly in Pongo with preread function executed) so any guidance on how to approach debugging this short of building a custom docker image and peppering in a bunch of log statements in the Kong lua would be appreciated.

I am currently testing with Kong 2.1.3 and Kong Ingress Controller 0.9.1

Below is the barebones schema utilized for testing incase that helps

local typedefs = require "kong.db.schema.typedefs"

local plugin_name = ({...})[1]:match("^kong%.plugins%.([^%.]+)")

local schema = {
  name = plugin_name,
  fields = {
    { config = {
        type = "record",
        fields = {
          { grants = { type = "array", elements = typedefs.ip_or_cidr, }, },
        },
      },
    },
  },
}

return schema

edit:

Forgot to include that the plugin is associated with the service that is being used for testing - similar to how the Pongo tests are setup save that we are db-less in Kubernetes.

2

Ive resolved this issue and have outlined the process by which I debugging this below as well as provided the resolution incase someone hits this in the future.

I ended up building a custom version of the kong docker image and just started at the outer layers of the onion, adding several kong.log.inspect statements to observe state and worked my way in ultimately to PluginsIterator.new (kong/runloop/plugins_iterator.lua) and observing that while the plugin was a loaded plugin it was not present it was not added to the workspace.

This was due to it not being added to the combos which was a result of a misconfiguration within my plugin definition, where I was omitting the protocols definition of KongPlugin which defaults to http/https, and in my case needed to be tcp/tls. This configuration deviated from my test case where protocols was explicitly defined for each case. Once the change was deployed the plugin functioned as expected.

Hope this may help someone in the future!

3

Hello, I’m from the future and this was very helpful for my issue.
Thanks!