fix(plugins): load wasm filter plugins before external plugins #13931
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
In 4059a31 (#13843) we added a plugin-like interface for Wasm filters.
We now have 3 sources for plugins: Lua, External, and Wasm Filters. When a plugin is enabled or configured, the plugin system follows a resolution order for looking up the plugin handler and schema:
require kong.plugins.<name>.{handler,schema}
kong.runloop.plugin_servers.load_{handler,schema}(<name>)
kong.runloop.wasm.plugins.load_{handler,schema}(<name>)
When a user configures Kong with a "bad" entry in
pluginserver_names
(read: a plugin server that is not actually installed), step #2 of the plugin resolution process throws an exception, because the external plugin subsystem attempts to query a plugin server that does not exist. Importantly, this exception is not encountered when the user has only configured/enabled Lua plugins, because we never reach beyond step #1 of the plugin resolution process.A side effect of adding the Wasm filter plugin interface is that discovered Wasm filters are added to the global plugins table (
kong.configuration.loaded_plugins
) when Wasm is enabled. This means that, if Wasm is enabled, and any Wasm filters are installed, we always step through step #2 of the plugin resolution process, triggering an exception if the user has any badly-configured plugin server.A future change will likely render this scenario unreachable by performing deeper validation of
pluginserver_names
at startup. For now, a simple fix is just to change the resolution order such that Wasm filters are loaded before we query the external plugin subsystem:Checklist
A changelog file has been created(this fixes an unreleased bug)There is a user-facing docs PRIssue reference
KAG-5911