Validate Configuration
The example validator treats component configuration as one coherent contract. It
requires strings and booleans where declared, accepts only observe or enforce for
requests.mode, requires arrays of strings for block and redaction keys, verifies
integer priorities, and reports every unknown component-local field under a stable code.
Validation does not open a client, register middleware, emit an event, or alter active configuration. Relay validates disabled components too, which lets an operator stage a future component and discover its mistakes before rollout.
Return the Same Diagnostic Shape
The following implementations return the same diagnostic fields while using each binding’s native configuration types:
Python
Node.js
Rust
The checked implementations continue beyond these excerpts by checking every boolean, integer, string, and string-array field. The important ordering is visible here: report unknown paths, deserialize or merge defaults, then apply semantic rules to the normalized value. A wrong object shape therefore produces a type diagnostic instead of an exception that escapes validation.
Rust receives the host ConfigPolicy only through validate_with_policy. The default
implementation calls validate and preserves existing custom-plugin behavior, so a Rust
plugin that claims policy-controlled unknown-field diagnostics must override the policy
method. Python and Node.js component hooks receive only component-local config; their
example makes its unknown-field policy an explicit part of the implementation contract.
One unsupported value returns equivalent data in every binding:
Preflight the Effective Document
Use the following procedure to prove that validation remains separate from activation:
- Register
documentation-plugin, then call the binding’s list function. Rust useslist_plugin_kinds, Python useslist_kinds, and Node.js useslistKinds. The kind should appear even though no component is active. - Construct a component with
enabled = falseandrequests.mode = "invalid". Callvalidate_plugin_config,plugin.validate, orplugin.validate. Confirm the report containsdocumentation-plugin.unsupported_modeand that the active report remains unchanged. - Correct the mode, give
requests.prioritya string, and confirm the error identifies that field. Restore the integer, add an unknown key, and confirm that the Python and Node.js examples return their documented warning while the Rust example follows the suppliedConfigPolicy. - Validate the shared correct configuration. The report should have no error-level diagnostics.
- Remember that
initializealso layers discoveredplugins.tomlconfiguration. In a deployment that uses file discovery, validate the effective startup source rather than assuming an isolated in-memory report describes the final activation.
Success means every binding catches the same invalid values before registration, a disabled component remains visible to validation, diagnostics are stable enough for automation, and the valid configuration proceeds to registration without a second interpretation of its fields.