These methods are not chained through the next_ops structure, so we must do that work in src/filters.c. This fixes the behaviour of filters when you layer multiple filters in front of a plugin. --- src/filters.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/src/filters.c b/src/filters.c index 18948bc..67f06d6 100644 --- a/src/filters.c +++ b/src/filters.c @@ -367,10 +367,17 @@ filter_prepare (struct backend *b, struct connection *conn) debug ("prepare"); - if (f->filter.prepare) - return f->filter.prepare (&next_ops, &nxdata, handle); - else - return f->backend.next->prepare (f->backend.next, conn); + /* Call these in order starting from the filter closest to the + * plugin. + */ + if (f->backend.next->prepare (f->backend.next, conn) == -1) + return -1; + + if (f->filter.prepare && + f->filter.prepare (&next_ops, &nxdata, handle) == -1) + return -1; + + return 0; } static int @@ -382,10 +389,14 @@ filter_finalize (struct backend *b, struct connection *conn) debug ("finalize"); - if (f->filter.finalize) - return f->filter.finalize (&next_ops, &nxdata, handle); - else - return f->backend.next->finalize (f->backend.next, conn); + /* Call these in reverse order to .prepare above, starting from the + * filter furthest away from the plugin. + */ + if (f->filter.finalize && + f->filter.finalize (&next_ops, &nxdata, handle) == -1) + return -1; + + return f->backend.next->finalize (f->backend.next, conn); } static int64_t -- 2.18.0