Validator for nested type in `[FromQuery]` parameter is considered even when not used

[cremor]

Example controller method:

[HttpGet]
public ActionResult<string> Get([FromQuery] FilterType filter)
{
    var validationResult = _filterTypeValidator.Validate(filter);

    if (!validationResult.IsValid)
    {
        return BadRequest(validationResult.Errors);
    }

    return filter.ToString();
}

Example types and validators:

public sealed record class FilterType
{
    public required FilterSubType RequiredSubType { get; init; }
}

public sealed record class FilterSubType
{
    public string? SubProperty { get; init; }
    public string? SubProperty2 { get; init; }
}

public sealed class FilterTypeValidator : AbstractValidator<FilterType>
{
    public FilterTypeValidator(IValidator<FilterSubType> filterSubTypeValidator)
    {
        RuleFor(x => x.RequiredSubType)
            .NotNull();
            // The 'FilterSubType.SubProperty' is marked as required even without the following line of code.
            //.SetValidator(filterSubTypeValidator);
    }
}

public sealed class FilterSubTypeValidator : AbstractValidator<FilterSubType>
{
    public FilterSubTypeValidator()
    {
        RuleFor(x => x.SubProperty).NotEmpty();
    }
}

Observation
The section Nested objects (SetValidator / ChildRules) in your readme explicitly mentions how you need to call nested validators. But even if you don't do that (like in my sample above with the SetValidator call commented out) the FilterSubType.SubProperty is still marked as required in the OpenAPI document.

So the API documentation claims that the property is required, but if you then actually call the API without that parameter (e.g. https://localhost:7095/api/test?RequiredSubType.SubProperty2=dummyValue) the validation doesn't fail.

Question
Is this by design? I'd understand if this is required for some other use case (e.g. types in request bodies) or if it makes the implementation easier. But if it's an easy fix then it would be nice to have.

[avgalex]

Fixed in 7.1.7-beta.2 (now on NuGet — MicroElements.Swashbuckle.FluentValidation, MicroElements.OpenApi.FluentValidation, MicroElements.AspNetCore.OpenApi.FluentValidation, MicroElements.NSwag.FluentValidation).

A nested type's validation is now reflected on a flattened [FromQuery] parameter only when the child is actually wired from the root validator via SetValidator/ChildRules — matching what FluentValidation enforces at runtime. In your example (FilterTypeValidator with the SetValidator commented out), RequiredSubType.SubProperty is no longer marked required, and no value constraints leak onto it. When you do wire SetValidator, the nested rules appear as before.

Note (behavioral): if there is no validator registered for the root [FromQuery] type (only a leaf/child validator), the flattened nested parameter is now left unconstrained too — again matching runtime, where no validation runs without a root validator.

Please give the beta a try and let me know if it behaves as expected. Leaving this open until you confirm.

Heads-up: this fix currently lives in the Swashbuckle OperationFilter (the default path). The same handling is being brought to the native Microsoft.AspNetCore.OpenApi transformer and the experimental DocumentFilter via #213. (NSwag is unaffected — it has no [FromQuery] flattening.)

[cremor]

I can confirm that this works as expected in 7.1.7-beta.2 for both my sample project and my real project. Thanks!

But I'd like to comment on this:

Note (behavioral): if there is no validator registered for the root [FromQuery] type (only a leaf/child validator), the flattened nested parameter is now left unconstrained too — again matching runtime, where no validation runs without a root validator.

I understand the reasoning behind this. But in theory a controller method could do the following and therefore not need a validator for the root object:

[HttpGet]
public ActionResult<string> Get([FromQuery] FilterType filter)
{
    var validationResult = new FilterSubTypeValidator().Validate(filter.RequiredSubType);
    // Rest removed
}

I understand that this is in contrast to my initial situation/question. But who knows how devs might implement their validation 😄

Maybe it would be enough to add that note that I quoted to the readme file?

[avgalex]

Thanks for confirming it works on your real project! 🙌

Your point is fair: if you validate the child manually (e.g. new FilterSubTypeValidator().Validate(filter.RequiredSubType)) without a validator for the root type, the constraints are enforced at runtime but the schema can't know that — there's no way to statically detect a .Validate() call inside a controller body, so the generator has to assume "no root validator ⇒ nothing validated". Wiring the child from a root validator (SetValidator/ChildRules) is the only signal it can rely on.

So, as you suggested, I've documented this in the README rather than changing the behavior — see the new "Nested [FromQuery] parameters" section (PR linked above). Leaving this issue open for you to close once you're happy with the note.

[cremor]

Looks good, thanks!