When one or more endpoints have the same Dto the firts one gets the FluentValidationRule and the next ones are not getting it

[jgarciadelanoceda]

This is a simple use case:

#!/usr/bin/env dotnet

#:sdk Microsoft.NET.Sdk.Web
#:package FluentValidation.AspNetCore@*
#:package MicroElements.Swashbuckle.FluentValidation@*
#:package Swashbuckle.AspNetCore@*
#:property PublishAot=false
#:property ManagePackageVersionsCentrally=false

using System.Reflection;
using FluentValidation;
using FluentValidation.AspNetCore;
using MicroElements.Swashbuckle.FluentValidation.AspNetCore;
using Microsoft.AspNetCore.Mvc;



var builder = WebApplication.CreateBuilder(args);


builder.Services.AddEndpointsApiExplorer().AddControllers()
.ConfigureApiBehaviorOptions(options =>
{
    options.SuppressInferBindingSourcesForParameters = true;
})
.Services
.AddSwaggerGen()
.AddFluentValidationAutoValidation()
.AddFluentValidationClientsideAdapters()
.AddValidatorsFromAssembly(Assembly.GetExecutingAssembly())
.AddFluentValidationRulesToSwagger(o => o.UseAllOfForMultipleRules = false);

var app = builder.Build();
app.UseSwagger();
app.UseSwaggerUI();
app.MapControllers();
app.Run();

[ApiController]
public sealed class ApiController : ControllerBase
{
    [HttpGet("/api/hello")]
    public string Hello(HelloRequest request) => $"Hello {request.Name ?? "world"}!";
	
	[HttpGet("/api/hello2")]
    public string HelloTwo(HelloRequest request) => $"Hello {request.Name ?? "world"}!";
}

public sealed class HelloRequest
{
    [FromQuery]
    public string? Name { get; set; }
}

public sealed class HelloRequestValidator : AbstractValidator<HelloRequest>
{
    public HelloRequestValidator()
    {
        RuleFor(x => x.Name)
        .NotEmpty()
        .MaximumLength(10);
    }
}

I like to put the RemoveUnusedQuerySchemas = true but finally I put it as false because I am losing the FluentValidationRules on the migration from version 6.0.0.0 to 7.1.8

I am happy to contribute anyway

[jgarciadelanoceda]

I have studied and basically it can´t work.. The library is removing the Schemas but not an internal dictionary of RevervedIds.. So the first one that comes it adds the schema.. And gets deleted.. But the internal dictionary of reservedNames is not modified https://github.com/domaindrivendev/Swashbuckle.AspNetCore/blob/d6ffe8195454a2ad30d1e6eaaef545504004ff3f/src/Swashbuckle.AspNetCore.SwaggerGen/SwaggerGenerator/SchemaRepository.cs#L5

As the OperationFilter is being run for every request this happens.. I note that you have an FluentValidationDocumentFilter.. That is experimental for now and it must the way to go for this issue to be solved.. I will take a look later

[avgalex]

@jgarciadelanoceda thank you for the excellent and precise investigation — you nailed the root cause, and it lines up exactly with the code. 🙏

Confirmed diagnosis

The bug is the interaction of three things:

1. FluentValidationOperationFilter runs once per operation (per endpoint).
2. The Issue Validators for records used with [AsParameters] create unused component schemas #180 cleanup (FluentValidationOperationFilter.cs, the block at the end of ApplyRulesToParameters) removes the temporary [FromQuery] container schema from SchemaRepository.Schemas when RemoveUnusedQuerySchemas = true.
3. Swashbuckle's SchemaRepository also keeps an internal reserved-ids map (RegisterType / TryLookupByType, the _reservedIds dictionary you linked) which our cleanup does not touch.

Step by step for two endpoints sharing HelloRequest:

• 1st endpoint — GetSchemaForType(HelloRequest) → type not reserved yet → GenerateSchema creates the full schema in Schemas and reserves the id in _reservedIds. Rules applied ✅. Then the Validators for records used with [AsParameters] create unused component schemas #180 cleanup removes HelloRequest from Schemas, but _reservedIds still holds it.
• 2nd endpoint — GetSchemaForType(HelloRequest) → not in Schemas anymore → GenerateSchema → Swashbuckle sees the type in _reservedIds (TryLookupByType) and returns a bare $ref schema without Properties, regenerating nothing. In SwashbuckleSchemaProvider.GetSchemaForType the $ref→concrete swap can't happen because the entry is no longer in Schemas, so the returned schema has Properties == null.
• The guard if (schema.Properties != null && schema.Properties.Count > 0) fails, so the whole rule-application block is skipped → the 2nd endpoint gets no rules. ❌

That is also why RemoveUnusedQuerySchemas = false "fixes" it: with the cleanup disabled, HelloRequest stays in Schemas, so the 2nd endpoint finds it and applies rules — at the cost of the unused query schema leaking into components, which is exactly what the flag was meant to avoid.

Plan

1. Add a failing regression test: two endpoints binding the same [FromQuery] DTO, asserting both parameters carry the FluentValidation constraints under RemoveUnusedQuerySchemas = true.
2. Make FluentValidationDocumentFilter production-ready and wire it up. As you noted, a document filter runs once for the whole document: it collects container types across all endpoints, de-duplicates them, generates each schema once, applies rules, and performs the Validators for records used with [AsParameters] create unused component schemas #180 cleanup a single time at the very end — so there is no per-operation Schemas/_reservedIds desync and shared DTOs work. We'll decide between replacing the operation filter and shipping it behind an opt-in switch to avoid regressions.

Contributions very welcome — happy to collaborate on the PR. Thanks again for digging into this. 🙌

[avgalex]

Update: opened #224 with a fix and a regression test.

A note on the approach

I initially leaned toward your suggestion of moving everything to the FluentValidationDocumentFilter. While implementing it I hit one detail worth calling out: FluentValidationOperationFilter also owns the request-body path — [FromForm]/[FromBody] and, importantly, Issue #216 (encoding.contentType for IFormFile parts via .FileContentType(...)), which is written at the operation level and cannot live in a schema/document filter alone. So a straight "replace the OperationFilter with a DocumentFilter" would have regressed #216 and the required-marking logic (#209).

For the immediate fix I therefore addressed the reserved-id desync at its source instead of restructuring the filters. In SwashbuckleSchemaProvider.GetSchemaForType, when the returned schema has no Properties and the id is absent from the shared repository (the reserved-but-removed state), the concrete schema is recovered by generating it into a throwaway SchemaRepository. It's fully isolated — it never mutates the shared repository or its reserved-id map — so it keeps the Issue #180 cleanup and all existing behavior intact (required #209, nested [FromQuery] #211/#213, request bodies, #216) while fixing the shared-DTO case for every endpoint. ~10 lines, one method, no registration changes → low regression risk.

This realizes the intent of your DocumentFilter idea (keep the SchemaFilter, fix the shared-DTO bug) with the smallest, safest change.

The full DocumentFilter is still worth doing — as a separate effort

Your architectural direction remains valuable. Making FluentValidationDocumentFilter production-ready and promoting it (it's currently Experimental, behind RegistrationOptions.ExperimentalUseDocumentFilter) is a larger piece of work with its own parity checklist:

• operationParameter.Required marking (Required property in optional nested type in [FromQuery] parameter is wrongly marked as required #209) — the DocumentFilter currently copies value constraints only;
• request bodies + [FromForm] + encoding.contentType (Add support for media types #216);
• full component-schema coverage (response DTOs, nested SetValidator components) that the SchemaFilter handles today;
• robustness: FindParam only inspects the first operation of a path; the duplicate schemasForParameters computation; nullability/obsolete cleanup.

We'll track and ship that separately (call it "Variant B", roughly 2–3 days with the full test matrix), so it doesn't hold up the #223 fix. Contributions there are very welcome if you'd like to collaborate.

Thanks again for the sharp diagnosis that made #224 straightforward.