Close the remaining "caught" and "produces red" harness holes

Four sites where a check could report a verdict it had not established, or
detect a failure and then not turn it red.

assert_no_panic in both NAT suites read `docker logs ... || true`, so a
container that could not be read produced empty output, matched no panic
pattern, and returned success. The assertion's failure mode was
indistinguishable from its success condition. It now reports that absence of
panics is not established.

deb-install's apt capture discarded the exit status, so a failed docker exec
gave an empty capture that matched neither error pattern and reached the pass
branch. The status is now kept and checked before the output is inspected, with
the output still printed on failure.

wait_for_systemd printed a warning and returned success on timeout, so every
check after it read a system that may not have started its units. It now returns
non-zero and the caller abandons that distro leg rather than testing an
unstarted system.

interop's copy of count_log_pattern carried the same defect fixed in rekey: a
node whose logs could not be read contributed zero to eight expect-zero
assertions. Fixed the same way, and its consumer now reports the unreadable case
rather than comparing a sentinel against zero.

Each validated by breaking what it guards and by confirming the healthy path is
unchanged: an absent container now fails each check where it previously passed,
a readable panic-free container still passes, a real panic is still caught, and
a genuinely successful install still passes.
This commit is contained in:
Johnathan Corgan
2026-07-23 15:36:59 +00:00
parent c8a0ac5fca
commit 34a2561af7
4 changed files with 58 additions and 10 deletions
+8 -1
View File
@@ -291,14 +291,21 @@ assert_process_alive() {
return 0
}
# A container whose logs cannot be read has not been shown to be panic-free.
# See the companion note in stun-faults-test.sh: the previous `|| true` made
# this assertion's failure mode indistinguishable from its success condition.
assert_no_panic() {
local container="$1"
local logs
logs="$(docker logs "$container" 2>&1 || true)"
if ! logs="$(docker logs "$container" 2>&1)"; then
echo "could not read logs from $container; absence of panics is not established" >&2
return 1
fi
if grep -Eq "panicked at|RUST_BACKTRACE|fatal runtime error" <<<"$logs"; then
echo "panic detected in $container logs" >&2
return 1
fi
return 0
}
run_test() {
+9 -1
View File
@@ -143,13 +143,21 @@ assert_process_alive() {
return 0
}
# A container whose logs cannot be read has not been shown to be panic-free.
# The previous form read `docker logs … || true`, so an unreadable container
# yielded empty output, matched no panic pattern, and returned success — the
# assertion's failure mode was indistinguishable from its success condition.
assert_no_panic() {
local logs
logs="$(docker logs "$NODE" 2>&1 || true)"
if ! logs="$(docker logs "$NODE" 2>&1)"; then
echo "could not read logs from $NODE; absence of panics is not established" >&2
return 1
fi
if grep -Eq "panicked at|RUST_BACKTRACE|fatal runtime error" <<<"$logs"; then
echo "panic detected in $NODE logs" >&2
return 1
fi
return 0
}
# Look for STUN-related fault evidence in the daemon's logs. The