pub struct ServerConformanceViolation {
pub timestamp: DateTime<Utc>,
pub method: String,
pub path: String,
pub client_ip: String,
pub status: u16,
pub reason: String,
pub category: String,
pub occurrences: u32,
pub client_mockforge_version: Option<String>,
pub client_sent_at: Option<DateTime<Utc>>,
pub summary: String,
pub categories: Vec<String>,
}Expand description
A single server-side conformance violation captured at the OpenAPI
router. Mirrors ConformanceViolation semantics from the bench-side
client validator so consumers can use the same dashboards.
Fields§
§timestamp: DateTime<Utc>When the request was rejected.
method: StringHTTP method (uppercase).
path: StringSpec-template path the request matched (e.g. /users/{id}).
client_ip: StringClient IP if available, else "unknown".
status: u16HTTP status the server replied with (typically 400 or 422).
reason: StringShort, human-readable reason — derived from the validator error.
category: StringSpec category the violation falls into ("parameters",
"request-body", "headers", etc.). Empty if the validator
couldn’t classify.
occurrences: u32Round 30 — number of times this signature has been observed.
Always 1 in FIFO mode (the default). In unique-buffer mode
(MOCKFORGE_CONFORMANCE_BUFFER_UNIQUE=true) every duplicate
hit bumps this counter on the existing entry instead of
consuming a new buffer slot. Defaults to 1 when deserialising
older payloads that don’t carry the field.
client_mockforge_version: Option<String>Round 36 (#876) — mockforge version the client (the bench
driver) was running when it sent the request, as read from the
X-Mockforge-Client-Version header. None when the inbound
request didn’t carry the header (older client, real proxy
traffic, etc.). Lets users cross-correlate a client-side
CaseCapture JSONL line with the matching server-side
violation when both sides log against the same code base.
client_sent_at: Option<DateTime<Utc>>Round 36 (#876) — wall-clock timestamp the client stamped on
its CaseCapture, as read from the X-Mockforge-Client-Sent-At
header (RFC3339). Server-side timestamp is when the
violation was received; this is when the probe was sent.
Grep both for the same value to line up client + server
records of the same probe.
summary: StringRound 44 (#79) — short human-readable summary of reason, for
dashboards / report tables that don’t want to display the full
JSON-shaped validator error. Built once at insertion time from
reason via summarize_reason; empty when the caller didn’t
supply one. Older payloads without this field deserialise as
empty so consumers can fall back to reason.
Srikanth on 0.3.188: “What is the difference between Validation error: and errors both the content seems similar with few differences here and there… The reason I am asking is both the errors are overwhelming to view.”
categories: Vec<String>Round 47 (#79) — Srikanth on 0.3.191: “I will not know other
violations until previous ones are fixed. Is it possible to
give a option to show all the violation irrespective of the
order both on client request logs and mockforge tui logs”.
category already records the priority-winning location for
dashboards that filter by single category; categories lists
EVERY distinct location the validator’s details[] payload
surfaced (e.g. ["query","request-body"] for a POST that
failed both a query enum AND a required body field). Empty
when the validator didn’t embed a structured details map.
Older clients deserialise this as empty and fall back to
category alone.
Trait Implementations§
Source§impl Clone for ServerConformanceViolation
impl Clone for ServerConformanceViolation
Source§fn clone(&self) -> ServerConformanceViolation
fn clone(&self) -> ServerConformanceViolation
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more