Repository navigation
test(audit): give the native audit example a timeout its reinit phase fits - #66
Conversation
… fits The generation-race phase reinitializes the module inside the audit callback. On a loaded macOS runner that took about 107 ms, past the fixture's 100 ms audit wait, so the receipt was never committed and the example failed intermittently. One module serves every phase and its audit settings are immutable across reinit, so raise the shared wait to 1000 ms. The never-replying phase still times out well inside the 3 s client wait.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
Tiny Sweeper reviewReviewed head: Verdict: Ready for maintainer review · Priority: none Diagnostics and supporting detailsFull summaryPull request purpose (title): test(audit): give the native audit example a timeout its reinit phase fits. Tiny Sweeper completed its review; deterministic results follow. Review snapshot
Completeness: Complete What changedIn `crates/tinysecurity-module/examples/audit_native_contract.rs`, the fixture's audit-sink deadline is replaced: the hard-coded `timeout_ms: 100` in `audit_config` now reads `AUDIT_TIMEOUT_MS`, a named `u32 = 1000` constant. The accompanying comment explains that one module serves every phase and its audit settings are immutable across reinit, so a single value must fit them all: mode 6 reinitializes the module inside the callback (about 107 ms on a loaded macOS runner, past the old 100 ms), while mode 3 deliberately never replies and must still time out well inside the 3 s client wait. The change is confined to the example fixture. Features
TestsNo supported feature-to-test mapping was produced. Test execution is not inferred. FindingsNo active actionable findings. Before mergeNone. Agent review detailscritique
security
tests
commits
description
Evidence and run details
|
Summary
The
audit_native_contractexample failed intermittently on macOS. Its generation-race phase reinitializes the module from inside the audit callback. On a loaded runner that took about 107 ms, while the fixture's audit wait (AuditConfig2.timeout_ms) was 100 ms. So the module stopped waiting before the callback replied, nothing was committed, and the example failed at "generation change must deny permission without erasing the durable receipt".The example loads one module for every phase, and its audit settings are immutable across reinit (the example itself asserts this). So the wait cannot differ per phase. It is now 1000 ms, a named constant with the reason next to it. The phase whose callback never replies still exercises the timeout, and it still ends well inside the 3 s client wait.
Related issue
None. It's flaky CI, seen on #65's macOS job.
API or behavior changes
None. Only the example's fixture changes.
Validation
Commands actually run, on our Linux CI runner at 3e158e3 (rustc 1.99.1):
cargo fmt --all -- --check: cleancargo clippy --all-targets --all-features -- -D warnings: 0 warningscargo build -p tinysecurity-module --lib --examples --all-features: okcargo test --package tinysecurity-module --example audit_native_contract: 3 passed, 0 failedThat Linux runner is fast enough that the old 100 ms also passes there, so these runs show the change breaks nothing; they do not reproduce the macOS flake. The macOS job in this PR's CI is where the 107 ms case was seen.
Tests
No new test; the example is the test. Its timeout phase is unchanged in what it checks.
Documentation
Not needed. The constant's comment records why the value is what it is.
Checklist
#[allow(...)],#[ignore], or relaxed lints.envcontents in the diff or the description