Module invariant

Modules§

CheckSequenceOptions: Options controlling how check_sequence evaluates a candidate call sequence.
HandlerAssertionFailure: A handler-side assertion bug: a require/assert inside a fuzzed handler that the campaign reached. Deduped by (reverter, selector) site (Echidna/Medusa semantics), shortest sequence wins on collision.
HandlerReplayOutcome: Result of a strict handler-bug replay: anchor asserts, no earlier call asserts, and the recomputed edge fingerprint identifies which path the assertion took.
InvariantExecutor: Wrapper around any Executor implementer which provides fuzzing support using [proptest].
InvariantFailures: Stores invariant test failures and revert counts.
InvariantFuzzTestResult: The outcome of an invariant fuzz test
InvariantMetrics: Contains invariant metrics for a single fuzzed selector.

FailureKey: Identifies a single entry in the InvariantFailures map. Invariant predicate failures and handler-side assertion bugs share one map keyed by this enum.
InvariantFuzzError

check_sequence: Checks if the given call sequence breaks the invariant.
check_sequence_value: Executes a call sequence and returns the optimization value (int256) from the invariant function. Used during shrinking for optimization mode.
handler_site_already_minimal: True iff there is already a HandlerAssertionFailure for site no longer than candidate_len. Used to skip inserting a not-strictly-shorter repro.
replay_error: Replays and shrinks a call sequence, collecting logs and traces.
replay_handler_failure_sequence: Replays a handler-bug sequence and returns whether the anchor still asserts on the same path. Rejects sequences with a pre-anchor assertion (would be a different bug).
replay_run: Replays a call sequence for collecting logs and traces. Returns counterexample to be used when the call sequence is a failed scenario.