[GH-ISSUE #2835] Flaky test: `resolver::dnssec::regression::can_validate_ns_query_case_randomization` #1072

New issue

Closed

opened 2026-03-16 01:32:13 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:32:13 +03:00

Owner

Originally created by @divergentdave on GitHub (Mar 7, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2835

This test has failed in CI for me twice recently.

failures:

---- resolver::dnssec::regression::can_validate_ns_query_case_randomization stdout ----

thread 'resolver::dnssec::regression::can_validate_ns_query_case_randomization' panicked at packages/conformance-tests/src/resolver/dnssec/regression.rs:156:5:
assertion failed: saw_response

Originally created by @divergentdave on GitHub (Mar 7, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2835 This test has failed in CI for me twice recently. ``` failures: ---- resolver::dnssec::regression::can_validate_ns_query_case_randomization stdout ---- thread 'resolver::dnssec::regression::can_validate_ns_query_case_randomization' panicked at packages/conformance-tests/src/resolver/dnssec/regression.rs:156:5: assertion failed: saw_response ```

kerem closed this issue

2026-03-16 01:32:19 +03:00

kerem commented

2026-03-16 01:32:24 +03:00

Author

Owner

@divergentdave commented on GitHub (Mar 10, 2025):

I think the issue is that the response from the resolver to the client may sometimes be lost in the capture buffer, if it is not read before tshark gets killed. Currently, Tshark::wait_for_capture() reads logging from stderr that indicates how many packets have been captured, while Tshark::terminate() sends SIGKILL, consumes the rest of stderr, and then parses captured packets received from the stdout-reading thread. Packet counts are not practical to use here, so I think we should rewrite Tshark to parse captured packets as they arrive, and provide a wait_until() method that lets us check some predicate over the packets captured so far.

@divergentdave commented on GitHub (Mar 10, 2025): I think the issue is that the response from the resolver to the client may sometimes be lost in the capture buffer, if it is not read before `tshark` gets killed. Currently, `Tshark::wait_for_capture()` reads logging from stderr that indicates how many packets have been captured, while `Tshark::terminate()` sends SIGKILL, consumes the rest of stderr, and then parses captured packets received from the stdout-reading thread. Packet counts are not practical to use here, so I think we should rewrite `Tshark` to parse captured packets as they arrive, and provide a `wait_until()` method that lets us check some predicate over the packets captured so far.

kerem referenced this issue

2026-03-16 04:00:20 +03:00

[PR #1072] [MERGED] Bump rusqlite from 0.21.0 to 0.22.0 #1942