-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior with Minimal Plugin Codebase Pattern #5853
Comments
I have not looked at the plugin’s code you pasted yet, but from just reading your report, this seems to be related to #5851. Not sure what happened here but it seems that kong.ctx.plugin and kong.log aren’t working when plugins yield during their execution anymore. #5851 fixes the kong.ctx.plugin issue already. |
I remember this plugin working fine in the past though, so I can either assume: 1.) Stripping a plugin of the base extender and removing the .super() boilerplate calls at the beginning of the phases are what hurt prior working behavior. I also added local kong = kong, but that should not be problematic I would think as other bundled plugins do it. 2.) Either a Kong pdk change or Kong version change hurt existing behavior somewhere in the 1.x.x series? Or maybe 1 and 2 both play a role together heh. Will apply the patch you linked to my dev env and will retest and confirm on if |
Hoping to test Friday now, got bogged down with other priorities. I see PR for the fix is still pending(and it may only fix the Edit Edit - I see a new PR has been done that should fix both these issues, will give them a go later tonight after dinner! |
* Store namespace keys in `ngx.ctx` to ensure all dynamically generated namespaces are isolated on a per-request basis. * Introduce a new global API (which is a private API for use by core only) to explicitly delete a namespace. A note on the benefits of this new implementation: * By using a table to keep track of namespaces in `ngx.ctx`, we ensure that users of `ngx.ctx` cannot access the table namespaces, thus properly isolating it and avoiding polluting `ngx.ctx` for core and/or plugins. We can think of it as a double-pointer reference to the namespace. Each request gets a pre-allocated table for 4 namespaces (of course not limited to 4), with the assumption that most instances do not execute more than 4 plugins using `kong.ctx.plugin` at a time. * We ensure that namespace key references cannot be `nil` to ensure a safe usage from the core. * All namespace key references are still weak when assigned to a namespace, thus tying the lifetime of the namespace to that of its key reference. Similarly to the previous implementation, this is done to ensure we avoid potential memory leaks. That said, the `kong.ctx.plugin` namespace does use the plugin's conf for that purpose anymore (See 40dc146), which alleviates such concerns in the current usage of this API. * All tables allocated for namespace key references and namespaces keys themselves will be released when `ngx.ctx` will be GC'ed. * We also ensure than `kong.ctx.*` returns `nil` when `ngx.ctx` is not supported ("init" phase). Co-Authored-By: tdelaune <[email protected]> Fix #4379 Fix #5853 See #5851 See #5459
#5873 should fix the issues here. |
Yeah started looking at 1.4.3 vs 2.x.x src to test your PR but so much has changed and refactored in the last year I don't want to invest backporting all these changes right now to go to prod as a fix(as only a few not critical feats of my plugins are impacted by the pdk kong.ctx.plugin.* + kong.log() it seems while running 1.4.3). Rather going to make a team effort push in the next 4-6 weeks to get on the latest 2.x.x series of Kong, been too far behind for too long I been building up so many patch files and lists of differences. fixed in newer versions vs my own. Planning on going to 1.5.x here shortly as a springboard to whatever 2.x.x version there will be. Sorry I could not assist here right now, will retest when I get there. |
* Store namespace keys in `ngx.ctx` to ensure all dynamically generated namespaces are isolated on a per-request basis. * Introduce a new global API (which is a private API for use by core only) to explicitly delete a namespace. A note on the benefits of this new implementation: * By using a table to keep track of namespaces in `ngx.ctx`, we ensure that users of `ngx.ctx` cannot access the table namespaces, thus properly isolating it and avoiding polluting `ngx.ctx` for core and/or plugins. We can think of it as a double-pointer reference to the namespace. Each request gets a pre-allocated table for 4 namespaces (of course not limited to 4), with the assumption that most instances do not execute more than 4 plugins using `kong.ctx.plugin` at a time. * We ensure that namespace key references cannot be `nil` to ensure a safe usage from the core. * All namespace key references are still weak when assigned to a namespace, thus tying the lifetime of the namespace to that of its key reference. Similarly to the previous implementation, this is done to ensure we avoid potential memory leaks. That said, the `kong.ctx.plugin` namespace does use the plugin's conf for that purpose anymore (See 40dc146), which alleviates such concerns in the current usage of this API. * All tables allocated for namespace key references and namespaces keys themselves will be released when `ngx.ctx` will be GC'ed. * We also ensure than `kong.ctx.*` returns `nil` when `ngx.ctx` is not supported ("init" phase). Co-Authored-By: tdelaune <[email protected]> Fix #4379 Fix #5853 See #5851 See #5459
* Store namespace keys in `ngx.ctx` to ensure all dynamically generated namespaces are isolated on a per-request basis. * Introduce a new global API (which is a private API for use by core only) to explicitly delete a namespace. A note on the benefits of this new implementation: * By using a table to keep track of namespaces in `ngx.ctx`, we ensure that users of `ngx.ctx` cannot access the table namespaces, thus properly isolating it and avoiding polluting `ngx.ctx` for core and/or plugins. We can think of it as a double-pointer reference to the namespace. Each request gets a pre-allocated table for 4 namespaces (of course not limited to 4), with the assumption that most instances do not execute more than 4 plugins using `kong.ctx.plugin` at a time. * We ensure that namespace key references cannot be `nil` to ensure a safe usage from the core. * All namespace key references are still weak when assigned to a namespace, thus tying the lifetime of the namespace to that of its key reference. Similarly to the previous implementation, this is done to ensure we avoid potential memory leaks. That said, the `kong.ctx.plugin` namespace does use the plugin's conf for that purpose anymore (See 40dc146), which alleviates such concerns in the current usage of this API. * All tables allocated for namespace key references and namespaces keys themselves will be released when `ngx.ctx` will be GC'ed. * We also ensure than `kong.ctx.*` returns `nil` when `ngx.ctx` is not supported ("init" phase). Co-Authored-By: tdelaune <[email protected]> Fix #4379 Fix #5853 See #5851 See #5459
Can confirm 2.0.5 series did fix all this now that we are on it. Glad to be caught up on Kong versions finally and looking to push onward to 2.1 here in the next 1-2 weeks now! |
Summary
Following docs on minimal plugin logic, I rewrote a nice little simple tx debugger tool that helps log request and response headers, query parameters, and bodies.
Docs: https://docs.konghq.com/1.4.x/plugin-development/custom-logic/#handlerlua-specifications
Example modern handler.lua as well:
https://github.com/Kong/kong/blob/1.4.3/kong/plugins/jwt/handler.lua
Seems after converting it(and updating to modern schema) a bunch of pdk behavior isn't working anymore. Is this expected behavior or do I need to add the base plugin boiler plate logic back in? Plugin has just a handler.lua and schema.lua file
Noted behaviors:
kong.log() calls in the access phase are not printing anything. See "kong.log("Does it exist ever or log? " .. kong.ctx.plugin.request_body)" line in the handler.lua file. Never prints.
kong.ctx.plugin.* does not seem to persist and work across phases, all these references are nil between access to log phase etc.
Old code should be fully functional.
New Schema:
New Code:
Old Schema:
Old Code:
Steps To Reproduce
Additional Details & Logs
The text was updated successfully, but these errors were encountered: