@keenjus Thanks for filing this issue, Martin! Your repro checks out for me.

I believe the hiccup here is related to the polymorphic subtype referencing the parent in the generic type argument for the collection. I'll add a test case to our suite for this and see what the fix would look like.

ComponentDtoSectionDto - does Microsoft.AspNetCore.OpenApi support custom names? I don't like the auto-generated one.

We do support customizing the names for types, but unfortunately at the moment it won't allow you to modify the name of the polymorphic type entirely (e.g. BaseType + Subtype). :/

What kind of name would you prefer to see here?

Ideally I would like derived types to use their type names, so instead of ComponentDtoSectionDto it would be just SectionDto (Swashbuckle does it this way when using the same polymorphic types).

Full control over generated names would also be nice, so the current name generation wouldn't need changing.

I believe the hiccup here is related to the polymorphic subtype referencing the parent in the generic type argument for the collection. I'll add a test case to our suite for this and see what the fix would look like.

Following up on this: I'm moving this out of 9.0.0 since I need to spend a little bit more time fleshing out the fix and the window for bringing changes in .NET 9 is closing soon. This will have to come in a servicing patch for 9.0.

Full control over generated names would also be nice, so the current name generation wouldn't need changing.

Other folks have asked for this so I'll open a separate API proposal for it.

@captainsafia How do I influence the naming of schemas based on the .NET type? To remove a "Dto" suffix. I can't seem to find that in the documentation. I've tried the known transformers but no luck.

I'm moving my 20+ services from NSwag.

An equivalent to this:

    public class CustomSchemaNameGenerator : ISchemaNameGenerator
    {
        public string Generate(Type type)
        {
            if (type.IsGenericType)
            {
                return $"{type.Name.Replace("`1", string.Empty)}Of{GenerateName(type.GetGenericArguments().First())}";
            }
            return GenerateName(type);
        }

        private static string GenerateName(Type type)
        {
            return type.Name
                .Replace("Dto", string.Empty);
            //.Replace("Command", string.Empty)
            //.Replace("Query", string.Empty);
        }
    }

@captainsafia

I dug into the source code and found that the actual name that will be used as reference id, or key, in the completed schema is stored under Annotations with the key x-schema-id.

I can modify that like so:

        options.AddSchemaTransformer(static (schema, context, ct) =>
        {
            const string SchemaId = "x-schema-id";

            if (schema.Annotations?.TryGetValue(SchemaId, out var referenceIdObject) == true
                 && referenceIdObject is string newReferenceId)
            {
                newReferenceId = GenerateSchemaName(context.JsonTypeInfo.Type);

                schema.Annotations[SchemaId] = newReferenceId;

                Console.WriteLine(newReferenceId);
            }

            return Task.CompletedTask;
        });

The type OpenApiConstants is not public. Otherwise, I would have used OpenApiConstants.SchemaId.

I initially wondered why the doc.Component.Schema wasn't set in the Document Transformer. But found out that the last step of creating the document is this special transformer OpenApiSchemaReferenceTransformer that runs last.

Anyway, I'm starting to understand how this works. Not that different from any compiler having to keep track of references to types, members, and variables etc. 🙂

I'm also getting the same ArgumentException: An item with the same key has already been added., which unfortunately blocks me from updating my project to .NET 9 at this point.

I'm also getting the same ArgumentException: An item with the same key has already been added., which unfortunately blocks me from updating my project to .NET 9 at this point.

work with Swagger, when I try to migrate to OpenApi, get same error

Swagger:

builder.Services.AddSwaggerGen(options =>
{
    options.SchemaGeneratorOptions.UseOneOfForPolymorphism = true;
    options.SchemaGeneratorOptions.SubTypesSelector = baseType =>
        baseType.GetCustomAttributes<JsonDerivedTypeAttribute>().Select(x => x.DerivedType);
    options.SelectDiscriminatorNameUsing(baseType => baseType.GetCustomAttribute<JsonPolymorphicAttribute>()?.TypeDiscriminatorPropertyName ?? "$type");
    
    Type? SearchParentRecursive<T>(Type type) where T : Attribute
    {
        if(type.BaseType is null || type == typeof(object))
        {
            return null;
        }
        
        var attribute = type.BaseType.GetCustomAttribute<T>();
        if (attribute is null)
        {
            return SearchParentRecursive<T>(type.BaseType);
        }
        
        return type.BaseType;
    }
    options.SelectDiscriminatorValueUsing(subClass => SearchParentRecursive<JsonPolymorphicAttribute>(subClass)!.GetCustomAttributes<JsonDerivedTypeAttribute>().FirstOrDefault(x => x.DerivedType == subClass)!.TypeDiscriminator?.ToString());
});

I'm also experiencing issues generating OpenAPI documentation for polymorphic types. I want to bind a collection of a fairly complex polymorphic type from a request. It works perfectly fine when binding only a single instance. If I use IEnumerable<T>, List<T>, or Collection<T>; it fails with An item with the same key has already been added. Key: keyName

We generate the documentation at compile-time, but I don't believe it makes any difference

Any updates on this?
I have run into this issue in two separate projects, and it's preventing us from moving to OpenAI OpenApi. The suggestions from @marinasundstrom does get it to generate a valid OpenApi document when using an "add random stuff to the model names" strategy, but that is not a feasible fix.

Still a problem in 9.0.1!

Facing the same issue

I am facing the same issue. A workaround for me was to change my DTO types from:

public record class BasePriceChangeDto(
    IEnumerable<KiloWattPriceRange> BasePrices) : GroupChangeDto

public record class ProductRuleChangeDto(
    ProductId ProductId,
    IEnumerable<KiloWattPriceRange> PriceRanges) : GroupChangeDto;

public record struct KiloWattPriceRange(KiloWattRange KiloWattRange, Price Price);

to:

public record class BasePriceChangeDto(
    IEnumerable<KiloWattPriceRange1> BasePrices) : GroupChangeDto

public record class ProductRuleChangeDto(
    ProductId ProductId,
    IEnumerable<KiloWattPriceRange2> PriceRanges) : GroupChangeDto;

public record struct KiloWattPriceRange1(KiloWattRange KiloWattRange, Price Price);
public record struct KiloWattPriceRange2(KiloWattRange KiloWattRange, Price Price);

@captainsafia why is it that when using the same nested type (doesn't matter if it is record struct, record class, or just plain old class) I get this error? The only change is to duplicate the nested types in the enumerable and give them separate names.

I also tried converting GroupChangeDto, BasePriceChangeDto, and ProductRuleChangeDto to plain class types to avoid having GetHashCode() be in record mode.

This issue is blocking us from switching from Swashbuckle to .NET 9 (Microsoft.AspNetCore.OpenApi).

I'm also having the same problem with Microsoft.AspNetCore.OpenApi 9.0.3

I've just re-tested this with Microsoft.AspNetCore.OpenApi 9.0.4 and the issue seems to have disappeared. Anyone else able to confirm?

@abbottdev I just tested the 9.0.4 on a smaller project and it spit out a valid openapi doc. I am going to try it out on a larger project on Monday, but so far it looks promising.

I think the AddOpenAPI might have just started ignoring the default JsonOptions, so even the bits that used to generate now don't.

.Configure(o =>
{
o.SerializerOptions.ReferenceHandler = ReferenceHandler.IgnoreCycles;
o.SerializerOptions.MaxDepth = 500;
});

fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
An unhandled exception has occurred while executing the request.
System.Text.Json.JsonReaderException: The maximum configured depth of 64 has been exceeded. Cannot read next JSON object. LineNumber: 0 | BytePositionInLine: 20767.
at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan1 bytes) at System.Text.Json.Utf8JsonReader.StartObject() at System.Text.Json.Utf8JsonReader.ConsumeValue(Byte marker) at System.Text.Json.Utf8JsonReader.ReadSingleSegment() at System.Text.Json.Utf8JsonReader.Read() at System.Text.Json.JsonDocument.Parse(ReadOnlySpan1 utf8JsonSpan, JsonReaderOptions readerOptions, MetadataDb& database, StackRowStack& stack)
at System.Text.Json.JsonDocument.ParseUnrented(ReadOnlyMemory1 utf8Json, JsonReaderOptions readerOptions, JsonTokenType tokenType) at System.Text.Json.JsonDocument.ParseValue(ReadOnlyMemory1 json, JsonDocumentOptions options)
at System.Text.Json.Nodes.JsonNode.Parse(String json, Nullable`1 nodeOptions, JsonDocumentOptions documentOptions)
at Microsoft.AspNetCore.OpenApi.OpenApiSchemaService.ResolveRelativeReferences(JsonNode node, JsonNode rootNode)
at Microsoft.AspNetCore.OpenApi.OpenApiSchemaService.ResolveRelativeReferences(JsonNode node, JsonNode rootNode)

Can also confirm that the 'An item with the same key has already been added' exception with polymorphic types in 9.0.4 no longer happens 🚀

Can also confirm that the 'An item with the same key has already been added' exception with polymorphic types in 9.0.4 no longer happens 🚀

still throw 'An item with the same key has already been added' exception with polymorphic types in 9.0.4

Still a problem for me on 9.0.5