Struct ServerlessRunner 

pub struct ServerlessRunner {
    functions: Vec<LuaRuntime>,
    plugin_type: &'static str,
}

Shared engine behind both serverless nodes: a compiled list of Lua functions run in order against the Context.

Each entry is a fully validated LuaRuntime (compiled at config load, so bad Lua fails policy compilation, not a live request). At request time the Context is threaded through every function: the table returned by one function’s execute becomes the input to the next. If any function errors, that error is propagated (routing the Context through the node’s error port); otherwise the final Context flows through the success port.

Fields

functions: Vec<LuaRuntime>

plugin_type: &'static str

Implementations

impl ServerlessRunner

pub fn from_config( config: &HashMap<String, Value>, plugin_type: &'static str, ) -> Result<Self, String>

Builds the runner from node config, compiling every function up front.

Accepted keys:

• functions (array of strings, required, ≥1): each string is Lua source defining a global execute(ctx) function. Each is compiled and validated here; an empty array, a non-string entry, a Lua syntax error, or a missing execute all fail at config load.
• phase (string, optional): accepted for APISIX compatibility but inert — placement in the graph determines phase.
• timeout_ms (integer, default 5000): per-function execution timeout passed to the Lua runtime (stored, not yet enforced by the VM).

pub fn run(&self, ctx: Context) -> Result<Context, PluginExecutionError>

Runs each function in order, threading the Context. Propagates the first error encountered.

Neither serverless-pre-function nor serverless-post-function declares a respond port (or any outcome port) — they use the default success/error pair. Each function therefore runs through LuaRuntime::execute_without_port, which rejects any second return value other than "success" (e.g. return ctx, "respond", or any other name) as LUA_BAD_PORT rather than silently dropping it: silently dropping it would let someone copy the script node’s respond idiom into a serverless function and get neither a response nor an error. The context reported on the error is the one that went into that function’s execute call (not the mutated table it returned), matching the script node’s rule that a function which did not finish making a decision keeps nothing it wrote.