pub struct Ctx {
pub client: Client,
pub depth: Depth,
pub lang: Lang,
pub claimed_model: String,
pub seed: u64,
pub perf: Mutex<Vec<PerfSample>>,
pub billing: Mutex<Vec<BillingRound>>,
pub headers: Mutex<Vec<BTreeMap<String, String>>>,
pub message_ids: Mutex<Vec<String>>,
pub raw_bodies: Mutex<Vec<String>>,
pub reachable: Mutex<bool>,
}Expand description
Shared state.
The locks are not buying mutual exclusion so much as Sync. This used to be
RefCell, which made every probe future !Send and therefore impossible to
await from a multi-threaded runtime: an embedded caller (a request handler
spawning a verification) could not hold the future at all. Nothing may hold
one of these guards across an .await; each site below takes it, reads or
pushes, and drops it in the same expression. That rule was a tidiness
convention while steps ran one at a time and is load bearing now that they
may not — see [run_steps].
Fields§
§client: Client§depth: Depth§lang: Lang§claimed_model: String§seed: u64The run’s seed. Every random payload is derived from it and from the id
of the step that asks — see Ctx::rng_for.
perf: Mutex<Vec<PerfSample>>§billing: Mutex<Vec<BillingRound>>§headers: Mutex<Vec<BTreeMap<String, String>>>Response headers from every successful call, for channel classification.
message_ids: Mutex<Vec<String>>§raw_bodies: Mutex<Vec<String>>§reachable: Mutex<bool>Set by the preflight probe; when false the rest of the run is pointless.
Implementations§
Source§impl Ctx
impl Ctx
pub fn new( client: Client, depth: Depth, lang: Lang, claimed_model: String, ) -> Self
Sourcepub fn with_seed(
client: Client,
depth: Depth,
lang: Lang,
claimed_model: String,
seed: u64,
) -> Self
pub fn with_seed( client: Client, depth: Depth, lang: Lang, claimed_model: String, seed: u64, ) -> Self
The same, on a caller-chosen seed.
Replaces the with_rng of earlier releases, which handed the whole run
one shared generator. That worked exactly as long as the steps ran in a
fixed order: draw order was step order, so a seed reproduced a run.
Under RunConfig::concurrency
it does not — whichever step wins the race draws first — and a seed that
reproduces a different set of questions each time is not a seed, it is
decoration. The generator is therefore per step now, and the id is half
of what seeds it.
Sourcepub fn rng_for(&self, step_id: &str) -> Rng
pub fn rng_for(&self, step_id: &str) -> Rng
A generator belonging to one step, and to one run.
Two steps never share a stream, so the payloads a seed produces do not depend on the order the scheduler happened to run them in, or on whether an earlier step was skipped. Same seed and same step id rebuild the same questions on any machine — which is what makes the seed in the report worth recording, and a contested verdict answerable question by question.
A step that draws more than once must therefore hold on to what this returns rather than calling again per draw, or every draw is the first draw. Steps that fan their requests out concurrently have to generate everything up front for the same reason.
Sourcepub fn observe(&self, raw: &RawResponse, id: &str)
pub fn observe(&self, raw: &RawResponse, id: &str)
Record everything a later probe might want from a raw response.
pub fn add_perf(&self, sample: PerfSample)
Sourcepub fn is_reachable(&self) -> bool
pub fn is_reachable(&self) -> bool
Whether the endpoint answered the preflight probe at all.