Module lua_plugin 

Support for Pact plugins written in Lua.

A Lua plugin is loaded as an embedded mlua interpreter running in the driver’s own process (executableType: "lua" in pact-plugin.json), instead of a separate child process speaking gRPC. The plugin script must define these global functions:

• init(implementation, version) -> table - returns an array of catalogue entries, each shaped as { entryType = "CONTENT_MATCHER", key = "...", values = { ... } }.
• configure_interaction(content_type, config) -> table - see PluginInstance::configure_interaction.
• match_contents(request) -> table - see PluginInstance::compare_contents.
• generate_content(contents, generators, test_mode) (optional) - see PluginInstance::generate_content.
• update_catalogue(catalogue) (optional) - see PluginInstance::update_catalogue.

A Lua plugin that registers a TRANSPORT catalogue entry (instead of, or as well as, a CONTENT_MATCHER/CONTENT_GENERATOR one) must also define these functions. The plugin itself is responsible for whatever the transport actually requires (opening sockets, making outbound calls, etc.) - the driver only calls these functions at the right points in the test lifecycle, exactly as it would over gRPC for an exec plugin:

• start_mock_server(request) -> table - see PluginInstance::start_mock_server / PluginInstance::start_mock_server_v2.
• shutdown_mock_server(server_key) -> table - see PluginInstance::shutdown_mock_server.
• get_mock_server_results(server_key) -> table - see PluginInstance::get_mock_server_results.
• prepare_interaction_for_verification(request) -> table - see PluginInstance::prepare_interaction_for_verification / PluginInstance::prepare_interaction_for_verification_v2.
• verify_interaction(request) -> table - see PluginInstance::verify_interaction / PluginInstance::verify_interaction_v2.

Each of these is called with either a V1-shaped or a V2-shaped request table, never both, depending on the plugin’s own pluginInterfaceVersion in its manifest - the same static, per-instance choice the driver makes for gRPC plugins (see plugin_manager.rs).

From within match_contents/generate_content, a script can also call back into a host-provided or another plugin’s capability, named by catalogue entry key (proposal 007, “Lua transport” - the in-process equivalent of the gRPC PluginHost callback service):

• host_compare_contents(entry_key, request) -> table - same request/response shape as match_contents itself, so a result can be returned straight through.
• host_generate_content(entry_key, contents, generators, test_mode) -> body - same arguments and return shape as generate_content itself.

These are only reachable from Lua code running inside match_contents/generate_content (the two entry points the driver invokes via call_async); calling them from another entry point currently fails, since mlua can only resolve an async host function from within a Lua call chain that was itself started asynchronously.

Structs

LuaPactPlugin

A running Lua plugin instance. Each instance owns its own embedded Lua VM.