You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2022-10-07 07:11:42,257 - INFO - request type:2, len:1792
2022-10-07 07:11:42,260 - ERROR - execute plugin `netsuite-authenticator` AnyError, ('Configuration is invalid json',)
2022-10-07 07:11:42,260 - INFO - response type:2, len:16
However apisix ignores the plugin and continues with the request to the upstream. This same occurs even if the exception is thrown in the filter() method.
I would prefer the ability to control this behaviour and I was expecting allow_degredation in apisix config to control the behaviour, but it seems this only apply to the plugin runner process itself, not errors from the plugin.
In some cases I also see the following errors immediately after the starting the plugin in dev mode due to the config token caching mechanism.
Again, apisix ignores the plugin and continues with the request to the upstream, but I would rather it didn't.
I believe this is happening because the plugin runner is always returning a successful RPC response, but the "action" in the response isn't set to either stop or rewrite, so apisix just assumes the plugin didn't want to do anything.
The text was updated successfully, but these errors were encountered:
Since python-plugin-runner does not modify ty's original type RPC_HTTP_REQ_CALL, apisix ignores the error, which seems to be an implementation problem with python-plugin-runner. 🤔
Also, errors throwed by config() are only logged in the execute() of python-plugin-runner, but are not passed to the function that calls execute(), and so are not passed to apisix.
allow_degredation
If the ty type problem described above can be fixed, it should be possible to get some errors here so that the allow_degradation should behave appropriately. 🤔
I'm not familiar enough with the code. 😅 @bzp2010 Pls help me check this.
Hello,
What is the intended behaviour of a plugin raising an exception?
e.g.
However apisix ignores the plugin and continues with the request to the upstream. This same occurs even if the exception is thrown in the filter() method.
I would prefer the ability to control this behaviour and I was expecting
allow_degredation
in apisix config to control the behaviour, but it seems this only apply to the plugin runner process itself, not errors from the plugin.In some cases I also see the following errors immediately after the starting the plugin in dev mode due to the config token caching mechanism.
Again, apisix ignores the plugin and continues with the request to the upstream, but I would rather it didn't.
I believe this is happening because the plugin runner is always returning a successful RPC response, but the "action" in the response isn't set to either stop or rewrite, so apisix just assumes the plugin didn't want to do anything.
The text was updated successfully, but these errors were encountered: