nic-6443 commented on issue #13724: URL: https://github.com/apache/apisix/issues/13724#issuecomment-6652185667
I'm closing this as not planned. The analysis here is correct, but I don't think making `_meta.filter` work with response variables is the right fix. As this issue points out, it worked for loggers before 3.16, but only because they had nothing running before `log`. A filter decides whether a plugin runs, and a response variable only has a value after most of the plugin's work is done. #14156 tried letting the filter name the phase it's evaluated in. That does fix loggers and a few others like cors, but it can't cover everything: limit-conn has already counted the request by the time the status is known, and zipkin has already started its spans and sent its headers. It also means users have to understand which phase each plugin does its work in just to write a filter. And I haven't seen anyone hit this in production. So I'd rather go the other way and limit `_meta.filter` to request-time data, and stop supporting response variables as conditions. The `$status` = `0` problem here is triggered by exactly this kind of filter, so it goes away with it. The open PRs (#13727, #13790, #14156) all try to make response variables work in the filter, so they don't fit this direction. Until then, please don't use `$status`, `$upstream_status` or other response variables in `_meta.filter`. If you need to pick log entries by response status, filter them at the log backend. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
