Strange behaviour of imports in plugins

Questions
1

Background

  • I was trying to migrate to DB less mode with Kong: 2.6.0
  • I have one plugin that uses kong.db.connector for some tasks, specifically in this file.
  • The plugin source can be seen here
  • Now when I try to run the command $ kong config db_export -v, I get an error:
    repo.lua:6: attempt to index field 'db' (a nil value)
    • Full traceback (on running the command in shell attached to the docker container):
      XXXX/XX/XX 10:46:09 [verbose] Kong: 2.6.0
XXXX/XX/XX 10:46:09 [verbose] prefix in use: /usr/local/kong
XXXX/XX/XX 10:46:09 [verbose] reading config file at /usr/local/kong/.kong_env
XXXX/XX/XX 10:46:10 [verbose] prefix in use: /usr/local/kong
Error:
/usr/local/share/lua/5.1/kong/tools/utils.lua:705: error loading module 'kong.plugins.cluster-stats.handler':
.../local/share/lua/5.1/kong/plugins/cluster-stats/repo.lua:6: attempt to index field 'db' (a nil value)
stack traceback:
   .../local/share/lua/5.1/kong/plugins/cluster-stats/repo.lua:6: in main chunk
   [C]: in function 'require'
   ...ocal/share/lua/5.1/kong/plugins/cluster-stats/worker.lua:3: in main chunk
   [C]: in function 'require'
   ...cal/share/lua/5.1/kong/plugins/cluster-stats/handler.lua:1: in main chunk
   [C]: at 0xffffb695fa40
   [C]: in function 'xpcall'
   /usr/local/share/lua/5.1/kong/tools/utils.lua:698: in function 'load_module_if_exists'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:134: in function 'load_plugin_handler'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:221: in function 'load_plugin'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:273: in function 'load_plugin_schemas'
   /usr/local/share/lua/5.1/kong/cmd/config.lua:93: in function 'cmd_exec'
   /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:88>
   [C]: in function 'xpcall'
   /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:45>
   /usr/local/bin/kong:9: in function 'file_gen'
   init_worker_by_lua:48: in function <init_worker_by_lua:46>
   [C]: in function 'xpcall'
   init_worker_by_lua:55: in function <init_worker_by_lua:53>
stack traceback:
   [C]: in function 'error'
   /usr/local/share/lua/5.1/kong/tools/utils.lua:705: in function 'load_module_if_exists'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:134: in function 'load_plugin_handler'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:221: in function 'load_plugin'
   /usr/local/share/lua/5.1/kong/db/dao/plugins.lua:273: in function 'load_plugin_schemas'
   /usr/local/share/lua/5.1/kong/cmd/config.lua:93: in function 'cmd_exec'
   /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:88>
   [C]: in function 'xpcall'
   /usr/local/share/lua/5.1/kong/cmd/init.lua:88: in function </usr/local/share/lua/5.1/kong/cmd/init.lua:45>
   /usr/local/bin/kong:9: in function 'file_gen'
   init_worker_by_lua:48: in function <init_worker_by_lua:46>
   [C]: in function 'xpcall'
   init_worker_by_lua:55: in function <init_worker_by_lua:53>
  • This issue has been fixed so now it won’t break.

Solution:

  • Turns out that at the location where the error comes up there is an import statement importing kong.db.connector

  • Changing the import to kong.db and then accordingly updating the use of connector in the file fixes the issue.

  • The exact changes that fixed the issue can be seen here.

    NOTE: We also faced the same issue when trying to run tests with pongo, and the same error came up, we figured the solution out by looking at the source of other plugins. But this really doesn’t make much sense to me.

Question:

  • Why does this happen?
  • What changes in the two forms of import…?? To me, they look exactly the same.
2

I am not sure but I think that this kind of issue would occur only when running Kong Programmatically like in tests and for CLI commands, the dynamically generated table entries in a module are not there, the connector is one such thing (generated by an init call in Kong), and thus it fails, whereas when you would trigger a Kong instance manually it all would work normally.
This is my best guess, have seen some portions of code in Kong (inside the DB sub-module) based on which I have come up with this “theory”.
It can also be something queer related to how the import system works in Lua. Or both at the same time.