Skip to content

test(audit): give the native audit example a timeout its reinit phase fits - #66

Merged
senamakel merged 3 commits into
tinyhumansai:mainfrom
M3gA-Mind:fix/audit-example-reinit-timeout
Nov 12, 2026
Merged

senamakel merged 3 commits into
tinyhumansai:mainfrom
M3gA-Mind:fix/audit-example-reinit-timeout

Conversation

@M3gA-Mind

Copy link
Copy Markdown
Contributor

Summary

The audit_native_contract example 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: clean
  • cargo clippy --all-targets --all-features -- -D warnings: 0 warnings
  • cargo build -p tinysecurity-module --lib --examples --all-features: ok
  • cargo test --package tinysecurity-module --example audit_native_contract: 3 passed, 0 failed
  • The example run against the built module, 5 times: 5 of 5 pass every phase; the in-callback reinit took 36–50 ms against the new 1000 ms wait

That 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

  • The change is focused on one logical change
  • No new #[allow(...)], #[ignore], or relaxed lints
  • No secrets, tokens, or .env contents in the diff or the description

… 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.
@coderabbitai

coderabbitai Bot commented Nov 11, 2026 •

Copy link
Copy Markdown

Important

  • Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 098de0a7-289b-498c-b533-f9a2f574b146
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

@tinysweeper

tinysweeper Bot commented Nov 11, 2026 •

Copy link
Copy Markdown

Tiny Sweeper review

Reviewed head: 29966966c2a163b8e97f0e5a28a110f05405e5d9

Verdict: Ready for maintainer review · Priority: none
Coverage: Reviewed 1 of 1 files.
Pull request purpose (title): test(audit): give th…

Diagnostics and supporting details

Full summary

Pull 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

Change surface Files Review signal Count
Production 1 Active findings 0
Tests 0 Noted findings 0
Documentation 0 Resolved findings 0
Configuration 0 Pending checks/questions 0

Completeness: Complete
Test assessment: No supported feature-to-test mapping was available; this does not mean tests are absent or passed.

What changed

In `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

  • Modified — Named audit-sink timeout constant for the native audit contract fixture: Raises the fixture's audit-sink wait from 100 ms to 1000 ms so the in-callback reinit phase can complete before the module stops waiting to commit. The value stays within the module's validated 1..=30000 ms range and is consumed only by `audit_config`; the never-replying mode-3 callback still times out well inside the 3 s client proxy wait, the separate native mode overrides the timeout to 30 s, and `verify_optional_callback_loss` passes `required: false`, so neither is affected. (crates/tinysecurity-module/examples/audit_native_contract.rs, crates/tinysecurity-module/examples/audit_native_contract.rs fn audit_config(required: bool) -> AuditConfig2 {, crates/tinysecurity-module/examples/audit_native_contract.rs impl Interface for Callback {)

Tests

No supported feature-to-test mapping was produced. Test execution is not inferred.

Findings

No active actionable findings.

Before merge

None.

Agent review details

critique

  • Conclusion: Success
  • Scope reviewed: all assigned evidence
  • Positive: The answered critique lane found no defect in this file: the value stays within the 1..=30000 ms range the module validates and well inside the 3 s client proxy timeout used for mode 3, and the reasoning in the comment matches the code paths the lane could read.
  • Lane summary: The change raises the fixture's audit callback timeout from 100 ms to a named 1000 ms constant so mode 6's in-callback reinitialize fits, and the value stays within the 1..=30000 ms range the module validates and well inside the 3 s client proxy timeout used for mode 3. The reasoning in the comment matches the code paths I could read; I found no defect in this file. _The code index is behind this pull request (indexed at `f555538b51fc`), so retrieved context may be out of date._

security

  • Conclusion: Success
  • Scope reviewed: all assigned evidence
  • Positive: The answered security lane found no defects: the change only raises the audit callback timeout constant in an example fixture from 100 ms to 1000 ms with an explanatory comment, introduces no new input paths, network calls, or permission changes, and still fits inside the example's 3 s client wait and 35 s outer deadline.
  • Lane summary: This change only raises the audit callback timeout constant in an example fixture from 100 ms to 1000 ms, with a comment explaining the rationale; it introduces no new input paths, network calls, or permission changes. The example's own client wait is 3 s, so the new value still fits, and the fixture's outer deadline is 35 s. No defects found. _The code index is behind this pull request (indexed at `f555538b51fc`), so retrieved context may be out of date._

tests

  • Conclusion: Success
  • Scope reviewed: all assigned evidence
  • Positive: The answered tests lane found no defects and concluded the change is fixture-only, with no production behavior altered and the example itself exercising the path.
  • Lane summary: This is a fixture-only change: the audit timeout in the native contract example moves from 100 ms to a named 1000 ms constant, with a comment explaining why (mode 6 reinit took ~107 ms on a loaded runner; mode 3 must still time out inside the 3 s client wait). No production behaviour changes, so no test is required; the example itself is the exercise of that path. I could not verify the 3 s client wait or the mode 3/mode 6 timing claims from the diff alone, but nothing in the change is a defect. _The code index is behind this pull request (indexed at `f555538b51fc`), so retrieved context may be out of date._

commits

  • Conclusion: Success
  • Scope reviewed: all assigned evidence
  • Positive: The answered commits lane reported no sensitive content in committed files.
  • Lane summary: No sensitive content in committed files. _The code index is behind this pull request (indexed at `f555538b51fc`), so retrieved context may be out of date._

description

  • Conclusion: Success
  • Scope reviewed: all assigned evidence
  • Positive: The answered description lane found the description matching the diff: a single example fixture constant replacing the 100 ms audit wait with a named 1000 ms constant, with the body's claims about the reinit phase, the non-replying timeout phase, and the 3 s client wait consistent with the change.
  • Lane summary: The description matches the diff: a single example fixture constant replacing the 100 ms audit wait with a named 1000 ms constant, with a comment explaining why. The body's claims about the reinit phase, the non-replying timeout phase, and the 3 s client wait are consistent with the change; I found no defect to report. _The code index is behind this pull request (indexed at `f555538b51fc`), so retrieved context may be out of date._
Evidence and run details
  • Models: ladder/vectors-oai3, deepseek-v4.1-flash
  • Spend: $0.001648
  • Tokens: 93839 input · 2400 output · 12800 cached · 96 embedding
  • Updated: 2026-11-11T15:17:21Z
Head State Pass summary
3e158e31d722 ready for maintainer review 0 active finding(s), 0 resolved finding(s) (at 2026-11-11T13:11:20Z)
45319ee51aa5 ready for maintainer review 0 active finding(s), 0 resolved finding(s) (at 2026-11-11T13:15:32Z)
29966966c2a1 ready for maintainer review 0 active finding(s), 0 resolved finding(s) (at 2026-11-11T15:17:21Z)

tinysweeper 0.1.2

@tinysweeper tinysweeper Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tinysweeper found nothing blocking. Approving.

Diagnostics

Total spend: $0.0053

@senamakel
senamakel merged commit 572f234 into tinyhumansai:main Nov 12, 2026
34 of 39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants