mirror of
https://github.com/jmcorgan/fips.git
synced 2026-10-05 19:18:25 +00:00
Johnathan Corgan
242e619169
Two unrelated harness defects with the same shape: the run's verdict names something other than what actually went wrong. The nostr publish/consume suite treats a dead relay as a product failure. strfry is a third-party container and it has segfaulted mid-run, twelve milliseconds after both nodes connected; everything below that was a correct report of a dead relay, and the run failed on the peer-count wait with the only evidence of the real cause sitting in one container-log line ninety lines above the summary. Add a relay verdict that states the relay's own condition — gone, not running, restarted, or faulted per its log — and print it at the head of every diagnostics dump, which is what every failure path already goes through. A relay whose state or log cannot be read is reported as unestablished rather than as healthy. The verdict does not decide the run: a relay that faulted while the assertions still passed is noted and left passing, since the suite proved what it set out to prove. The setup-bucket refill test raced its own precondition. It delivered exactly three forged setups against a 50/s refill and asserted one had been refused, which holds only if all three finish inside one 20 ms window; on a loaded runner the bucket refilled mid-loop, the third setup was admitted, and the precondition failed on arrangement rather than on behaviour. Under the CI retry policy that reports as green with a flaky count, so nothing surfaced it. Drain against a 2/s refill, which a delivery would have to take 500 ms to outrun, and deliver until a refusal is actually observed rather than assuming three is enough, with a cap that says what a runner slow enough to reach it means. The refill half then waits out a full burst from empty. (cherry picked from commit ec0fadfd136e0f6a64551fab61d042e486861842)