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 <anton@khirnov.net> 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: example@example.net
> +To: example@example.com
> +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: example@example.net
> +To: example@example.com
> +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] example@example.net; large attachment (attachment inbox unread)
> +thread:XXX   2025-02-09 [1/1] example@example.net; 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 -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org