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