#[non_exhaustive]pub enum Outcome {
Matched {
rule_set_index: usize,
rule_index: usize,
},
Middleware {
file_path: String,
status: u16,
},
Fallback {
file_path: String,
status: u16,
},
Miss {
status: u16,
},
Error {
kind: String,
message: String,
},
}Expand description
What the server decided to do with the request.
§RFC 073 F-08: every variant here must actually be emitted
Before this RFC, server.rs emitted Miss { status: 0 } for
every request regardless of outcome — the correct index was
computed and discarded — and nothing was emitted at all for a
middleware match, a dyn-route fallback file, or a genuine 404.
Fallback and Miss already existed but were unused outside this
module’s own tests; Middleware is new, added because no existing
shape fit a middleware match (its own script path, not a rule-set
index, is what identifies which one answered).
§#[non_exhaustive] — added in the same change that added Middleware
§(REVIEW-001 F-02)
Adding Middleware here breaks any consumer with an exhaustive
match on Outcome, regardless of what the public-API baseline
diff shows — a new-variant addition is “additive” in the sense that
tool tracks (a new pub item exists), not in the sense that matters
to semver (a consumer’s exhaustive match stops compiling). Outcome
was the one public enum in this crate not already carrying this
attribute — ReloadHint, ServerState, ServerError,
ServerErrorKind and TlsKind all have it; RFC 052 (which added it
to five other types) never considered Outcome, so this gap
pre-dates this tranche and simply hadn’t been triggered by an actual
variant addition yet. Since this change breaks exhaustive matchers
either way, marking it now means every future variant is free —
the same reasoning RFC 052 used for the five types it covered.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Matched
Middleware
A Rhai middleware handled the request. file_path is the
matched middleware script’s own path (MiddlewareHandler::file_path),
mirroring Fallback’s use of a path over an index for the same
reason: it identifies which handler answered without requiring
a consumer to also have the server’s own middleware list on hand.