Defaults on queue.lua not working as expected

[SomnolentKalash]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.8.0.0

Current Behavior

Using queue.enqueue with queue config, instead of populating defaults from schema it is asserting the config directly causing queue to fail post concurrency_limit has been added, Need you to populate the defaults first when queue conf is passed in enqueue function

Expected Behavior

No response

Steps To Reproduce

No response

Anything else?

No response

[maxipavlovic]

Yep, same here:
kong-auth | 2024/10/07 16:35:21 [error] 241#0: *5153 failed to run log_by_lua*: /usr/local/share/lua/5.1/kong/tools/queue.lua:640: arg #1 (queue_conf) concurrency_limit must be a number kong-auth | stack traceback: kong-auth | [C]: in function 'assert' kong-auth | /usr/local/share/lua/5.1/kong/tools/queue.lua:640: in function 'enqueue' kong-auth | /usr/local/share/lua/5.1/kong/plugins/connect-auth/log.lua:347: in function 'execute' kong-auth | ...ocal/share/lua/5.1/kong/plugins/connect-auth/handler.lua:22: in function <...ocal/share/lua/5.1/kong/plugins/connect-auth/handler.lua:20> kong-auth | /usr/local/share/lua/5.1/kong/init.lua:465: in function 'execute_collected_plugins_iterator' kong-auth | /usr/local/share/lua/5.1/kong/init.lua:1831: in function 'log'

[StarlightIbuki]

IMO it's unclear whether the default value is for plugin configurations or the queue PDK APIs from the changelog. I suppose it's logical also to support the same default value for PDK calls. @vm-001 What do you think?

[vm-001]

@SomnolentKalash @maxipavlovic Are you using the queue.lua directly without defining the queue schema in the plugin schema?

Using enqueue directly requires providing all properties. The queue.lua is not yet part of the PDK, and has no backward compatibility guarantee.

The workaround would be

local queue_conf = {
  ...
  concurrency_limit = 1,
}
Queue.enqueue(queue_conf, handler, handler_conf, message)