Struct ConfigWarning 

#[non_exhaustive]
pub struct ConfigWarning {
    pub tool: String,
    pub param: String,
    pub rule: &'static str,
    pub detail: String,
}

One non-fatal finding from crate::config::ServerConfig::lint (Phase 128, D-07).

Why this exists instead of a validate() variant

ConfigValidationError is first-error-wins Result<(), _> with no warning channel, so D-07’s “warns” is unexpressible in that signature. A running server must NOT refuse to boot because a free-text body parameter has no max_length (D-05) — but the author still has to be told, and the startup log is what makes a later regression traceable. Hence a separate additive -> Vec<ConfigWarning> channel that leaves validate’s existing behaviour untouched.

[server.validation] strict = true is what promotes a finding into a ConfigValidationError::UncappedStringParam.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

tool: String

The [[tools]] name the finding concerns.

EMPTY for a server-level finding — an active [server.validation] opt-out belongs to the server, not to a tool.

param: String

The [[tools.parameters]] name the finding concerns.

EMPTY for a server-level finding, for the same reason as Self::tool — and ALSO empty for a TOOL-level finding, one that concerns the [[tools]] entry as a whole rather than any one parameter (lint_against_spec’s configured-template-not-in-spec is the live case). So the two fields encode three scopes, and this field alone does not distinguish server-level from tool-level: read it together with Self::tool, exactly as this type’s Display does. A consumer switching on scope should test BOTH.

rule: &'static str

Stable machine-readable rule identifier, e.g. "uncapped-string".

A &'static str rather than an enum so plan 07’s CLI and plan 09’s startup log can group and filter on it without either taking a dependency on a closed set that every new rule would widen.

detail: String

Human-readable explanation, including the remedy.

Author-facing, like ConfigValidationError’s messages and unlike a client-facing refusal: it may name config keys and declared limits. It never contains caller data — lint runs at load time with no request in scope.

Trait Implementations

impl Clone for ConfigWarning

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ConfigWarning

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Display for ConfigWarning

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Renders the THREE scopes the two sentinel fields encode, not two.

tool and param are independently empty-as-sentinel, so they describe a server-level, a tool-level, or a parameter-level finding. Branching on tool alone collapsed the middle case into the parameter arm and rendered a tool-level finding as ... 'get_cui' parameter '': ... — reachable today from ServerConfig::lint_against_spec, which emits configured-template-not-in-spec with a tool name and an empty param, and printed verbatim to the deploy log by pmcp-openapi-server.

impl Eq for ConfigWarning

impl PartialEq for ConfigWarning

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for ConfigWarning