A sentence or so about the overall goal here (e.g. excluding isolation) would improve the commit message.
As mentioned in reply to patch 1, some trivial tests of the modified python bindings is needed. I suspect it's probably simplest to add to bindings/python-cffi/tests/test_config.py, but I don't mind either way. Anton Khirnov <[email protected]> writes: > --- > test/T681-index-filter.sh | 84 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 84 insertions(+) > create mode 100755 test/T681-index-filter.sh > > diff --git a/test/T681-index-filter.sh b/test/T681-index-filter.sh > new file mode 100755 > index 00000000..6ef7b9e4 > --- /dev/null > +++ b/test/T681-index-filter.sh > @@ -0,0 +1,84 @@ > +#!/usr/bin/env bash > +test_description="indexing attachment with a filter" I would suggest "indexing attachments with an external filter" > +. $(dirname "$0")/test-lib.sh || exit 1 > + > +notmuch config set index.as_text ".*" > + > +cat <<EOF > $MAIL_DIR/attachment-empty.eml > +From: [email protected] > +To: [email protected] > +Subject: zero-size attachment > +Date: Sun, 09 Feb 2025 12:33:43 +0000 > +Message-ID: <177064044971.16863.empty@localhost> > +MIME-Version: 1.0 > +Content-Type: text/plain > +Content-Disposition: attachment; filename=foo.txt > +Content-Transfer-Encoding: base64 > + > +EOF > + > +MSG_FILE_LARGE=${MAIL_DIR}/attachment-large.eml > + > +cat <<EOF > $MSG_FILE_LARGE > +From: [email protected] > +To: [email protected] > +Subject: large attachment > +Date: Sun, 09 Feb 2025 12:33:44 +0000 > +Message-ID: <177064044971.16863.large@localhost> > +MIME-Version: 1.0 > +Content-Type: text/plain > +Content-Disposition: attachment; filename=foo.txt > +Content-Transfer-Encoding: base64 > + > +EOF > + > +{ for i in $(seq 65536); do echo $i; done } | base64 >> $MSG_FILE_LARGE > + > +notmuch new > + > +cat <<EOF > EXPECTED > +thread:XXX 2025-02-09 [1/1] [email protected]; large attachment > (attachment inbox unread) > +thread:XXX 2025-02-09 [1/1] [email protected]; zero-size attachment > (attachment inbox unread) > +EOF > + > +test_begin_subtest 'input ignored' > +notmuch config set index.filter "/bin/sh -c 'echo secretstring'" > +notmuch reindex '*' > +notmuch search "secretstring" | notmuch_search_sanitize > OUTPUT > +test_expect_equal_file EXPECTED OUTPUT > + > +test_begin_subtest 'input consumed' > +notmuch config set index.filter "/bin/sh -c 'cat - > /dev/null; echo > secretstring'" > +notmuch reindex '*' > +notmuch search "secretstring" | notmuch_search_sanitize > OUTPUT > +test_expect_equal_file EXPECTED OUTPUT I'm curious here, how does a failure manifest? > + > +test_begin_subtest 'interleaved IO' > +# this filter interleaves reads of increasingly large weird-sized blocks > +# with writes > +notmuch config set index.filter '/bin/sh -c " > +bs=53; > +while true; do > + dd bs=\$bs count=1 2>&1 >/dev/null | grep -q \"^0+0 records in$\" >&2 && > break; > + echo \$bs; > + bs=\$((\$bs+48)); > +done; > +echo secretstring; > +"' > +notmuch reindex '*' > +notmuch search "secretstring" | notmuch_search_sanitize > OUTPUT > +test_expect_equal_file EXPECTED OUTPUT > + > +test_begin_subtest 'exit failure' > +notmuch config set index.filter "/bin/sh -c 'echo secretstring; exit 1'" > +notmuch reindex '*' > +notmuch search "secretstring" | notmuch_search_sanitize > OUTPUT > +test_expect_equal_file /dev/null OUTPUT > + Is there some positive indication of error we can test for here? I have found that testing for empty output tends to hide things failing in unanticipated ways. > +test_begin_subtest 'exit signal' > +notmuch config set index.filter "/bin/sh -c 'echo secretstring; kill -ABRT > \$\$'" > +notmuch reindex '*' > +notmuch search "secretstring" | notmuch_search_sanitize > OUTPUT > +test_expect_equal_file /dev/null OUTPUT Same question here. _______________________________________________ notmuch mailing list -- [email protected] To unsubscribe send an email to [email protected]
