[waldekmastykarz]

Closes #2055

What

Adds a top-level devproxy validate command so developers and agents can check a Dev Proxy config without starting the proxy. It shares its implementation with the existing devproxy config validate and supports -c/--config-file and --output json. Exit code is 0 when the config is valid and 2 when it's invalid.

The PR also extends validation to mirror the checks Dev Proxy runs at startup:

• Plugin config sections are validated against their schemas. A section is checked only when it declares a $schema and validateSchemas isn't false. Errors are reported with the section name as the path.
• Schema version mismatches in plugin sections produce a warning.
• Plugins with no URLs to watch produce a warning. These plugins have no plugin-level or global urlsToWatch, so the proxy won't load them.
• A configSection that's referenced but missing produces a warning, because the plugin falls back to its defaults.

Design notes

• Missing URLs and missing config sections are reported as warnings, not errors. At runtime, --urls-to-watch or stdio mode can supply URLs, and a missing section isn't fatal, so marking the config as invalid would cause false negatives.
• validate goes through the same early standalone path as config validate in Program.cs, so it doesn't load plugins or start the proxy.

Tests

• Added ConfigValidateTests, which covers plugin URL warnings, missing sections, schema errors in sections, and the validateSchemas: false opt-out. It uses a fake schema handler, so the tests don't hit the network.
• The full solution builds, and all tests pass.

[Copilot]

🟡 Changes recommended

Validation mishandles CLI arguments and help, can crash on unexpected JSON types, emits an incompatible JSON envelope, and can skip plugin schema validation for valid section paths.

4 open issues

• Resolve plugin config sections with configuration key semantics · New
• Parse both validation commands with System.CommandLine · New
• Validate JSON root and $schema types before accessing them · New
• Emit validation JSON using the structured result envelope · New

What changed in this PR

Adds devproxy validate as a standalone shortcut to config validate, addressing #2055 so developers and agents can check configurations without starting the proxy.

Changes:

• Registers the top-level command with config-file selection and JSON output support.
• Extends shared validation with plugin-section schema checks and warnings for missing URLs, missing sections, and schema-version mismatches.
• Adds focused validation tests using a fake HTTP handler.

File	Description
DevProxy/​Program.cs	Updates the comment describing early standalone validation.
DevProxy/​Commands/​ValidateCommand.cs	Adds the top-level command and usage examples.
DevProxy/​Commands/​DevProxyCommand.cs	Registers validate and recognizes it for standalone routing.
DevProxy/​Commands/​ConfigCommand.cs	Shares validation helpers and adds plugin-setting checks.
DevProxy.Tests/​ConfigValidateTests.cs	Tests plugin warnings, schema errors, and schema-validation opt-out.

_{Review effort: Balanced}

[Copilot]

🟡 Changes recommended

Configuration validation diverges from runtime binding, causing valid configurations to be rejected and invalid plugin settings to go undetected.

5 open issues

• Match startup's case-insensitive Boolean handling for ValidateSchemas · New
• Resolve plugin properties case-insensitively like the runtime binder · New
• Look up the $schema key case-insensitively · New
• Reject non-string $schema values instead of skipping validation · New
• Support numeric array indices in config section paths · New

4 resolved since last review

• Emit validation JSON using the structured result envelope
• Validate JSON root and $schema types before accessing them
• Parse both validation commands with System.CommandLine
• Resolve plugin config sections with configuration key semantics

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

The validator diverges from startup behavior, rejecting valid configurations and accepting duplicate keys that cause startup to fail.

No open issues 🎉

5 previously missed issues

In code that hasn't changed since last review

Treat a null top-level schema as absent

DevProxy/​Commands/​ConfigCommand.cs:660

A top-level "$schema": null used to be treated as an absent schema, and startup likewise sees no schema URL. This new type check instead reports it as an error and exits 2, rejecting configurations that the proxy accepts. Treat JSON null as a missing schema and retain the existing no-schema warning.

Skip section checks for non-configurable plugins

DevProxy/​Commands/​ConfigCommand.cs:867

This checks every referenced section even when the plugin does not support configuration. For example, RetryAfterPlugin inherits the non-generic BasePlugin, and RegisterPlugin ignores its configSection entirely; a stale section containing an invalid $schema will nevertheless make this command reject a configuration that starts normally. Use the loaded plugin type to skip section checks for non-configurable plugins, matching RegisterPlugin.

Treat whitespace-only schema URLs as absent

DevProxy/​Commands/​ConfigCommand.cs:895

A whitespace-only schema URL is treated as absent by BasePlugin.ValidatePluginConfigAsync, but this check sends it to ValidateJsonAsync, which returns an error for the invalid URL. As a result, a configuration that the proxy accepts is reported invalid. Use the same whitespace check as startup.

Resolve flattened colon-separated configuration keys

DevProxy/​Commands/​ConfigCommand.cs:931

Splitting the path only works when each segment is a separate JSON property. Configuration providers also flatten literal colon-containing keys, so a section such as "profiles:settings": {"$schema": "..."} is accessible at profiles:settings at startup but is reported missing here, and its schema is never checked. Resolve flattened keys as well as nested properties when traversing the path.

Detect duplicate configuration keys case-insensitively

DevProxy/​Commands/​ConfigCommand.cs:967

The JSON configuration provider rejects duplicate flattened keys case-insensitively; it does not use the last value. For example, an otherwise-valid file containing both "urlsToWatch": ["https://a.example/*"] and "UrlsToWatch": ["https://b.example/*"] can pass this validator but fails at startup because both define the same array index. Detect duplicate configuration keys throughout the document and report a validation error instead of silently selecting the last value.

5 resolved since last review

• Support numeric array indices in config section paths
• Reject non-string $schema values instead of skipping validation
• Look up the $schema key case-insensitively
• Resolve plugin properties case-insensitively like the runtime binder
• Match startup's case-insensitive Boolean handling for ValidateSchemas

_{Review effort: Balanced}

[waldekmastykarz]

Addressed the "previously missed" items from the last review in 8b22509:

• Null top-level $schema: now treated as absent and falls through to the existing no-schema warning.
• Whitespace-only schema URLs: treated as absent, using the same check as startup (IsNullOrWhiteSpace).
• Duplicate keys: the config is now loaded through the real JSON configuration provider, so duplicate keys (case-insensitive) are reported as configFile errors, just as startup would fail on them.

Pushing back on two items:

• Skip section checks for non-configurable plugins: this would mean loading plugin assemblies from pluginPath during validation. That's heavier and has side effects (type loading, dependency resolution) that a quick, agent-friendly validate should avoid. Flagging an invalid $schema in a section that's referenced but unused is still useful feedback.
• Flattened colon-containing keys: startup's own section schema check (BasePlugin.ValidatePluginConfigAsync) resolves the section with root.TryGetProperty(Key), not flattened keys, so this edge case isn't schema-validated at runtime either. The validator already resolves nested paths and array indices. I'd rather not add more traversal heuristics for a rare pattern.

[Copilot]

🟡 Changes recommended

YAML configuration is checked with the JSON provider, causing valid YAML with case-insensitive key collisions to be rejected.

1 open issue

• Use the YAML provider to validate YAML input · New

_{Review effort: Balanced}

[Copilot]

🔵 Needs a closer look

Human assessment is needed because validation can diverge from runtime configuration and mistake schema retrieval failures for invalid settings.

No open issues 🎉

1 resolved since last review

• Use the YAML provider to validate YAML input

_{Review effort: Balanced}