OData - Same Named Function in Two Configurations Causes System.InvalidOperationException on Startup

[benhysell]

tldr - In the OData example project I added a function with the same name to two different configurations. The examples can no longer run. I used to be able to add functions with the same name to two different OData endpoints without issue.

Example Repo - https://github.com/benhysell/aspnet-api-versioning
Example Project - https://github.com/benhysell/aspnet-api-versioning/tree/master/samples/aspnetcore/SwaggerODataSample

Using the examples I've duplicated the MostExpensive function from Order to Person via the steps below to trigger the exception.

Steps to Reproduce

• Take the Example project SwaggerODataSample
• Modify the configuration of PersonModelConfiguration.cs to add function
  person.Collection.Function( "MostExpensive" ).ReturnsFromEntitySet<Person>( "People" );
  https://github.com/benhysell/aspnet-api-versioning/blob/master/samples/aspnetcore/SwaggerODataSample/Configuration/PersonModelConfiguration.cs#L34
• Note this same function exists in the OrderModelConfiguration.cs -- https://github.com/benhysell/aspnet-api-versioning/blob/c29e95940cbaa66784b38f864ed51c60a9971d55/samples/aspnetcore/SwaggerODataSample/Configuration/OrderModelConfiguration.cs#L31
• Run the application
• Exception is thrown ODataRouteBuilderContext.cs ln 252

Is it allowable to have the same named function in two different models? And if not why not?

[commonsensesoftware]

It should be allowable. Resolving an operation by its qualified name was previously an issue. I could have sworn I had a test for that. I'll have to spelunk some more. This seems to be the issue. I distinctly recall using SingleOrDefault to make sure this exact failure would happen in the event the name is ambiguous (as FirstOrDefault would likely be harder to understand or track down).

I did notice you copied the MostExpensive method verbatim from OrdersController. The OrdersController intentionally uses attribute-routing and PeopleController intentionally uses convention-based routing to demonstrate the different styles. I doubt that's the cause this issue, but you'll want to be careful with mixing and matching as it's bound to cause issues.

Since you already have a repro setup with the source, you might break inside ODataRouteBuilderContext.ResolveOperation. You might find why the function is not being resolved.

[benhysell]

@commonsensesoftware My sloppy cut and paste job on the examples was the fastest way to show the error. I have a much larger application where I do not mix and match different methods/schemas and I tripped over this issue.

In the attached screenshot:

In EdmModel.SchemaElements the element Name:"MostExpensive" shows up twice. Not sure how it gets to this point...

[commonsensesoftware]

Thanks.

I kind of gathered that from since you indicated Line 252. ;) I'm wondering why it wasn't resolved by FindBoundOperations. It would seem, there is a resolution case for collections missing against the entity set itself. That might explain how things fall through to this case and work with a single operation, but not with multiple. I was suspecting this might be the issue, but then I couldn't figure out how it worked at all. This behavior would explain how a uniquely named operation would yield a false positive.

I don't have IntelliSense handy. Is there a way to find or resolve an operation by qualifiedName + EntitySet? You can probably use Quick Watch to poke around in the EDM to figure what element the function is associated with. I expect it to be the entity set itself. I would then expect an extension method overload for FindBoundOperations, FindDeclaredOperations, or some similarly named method that will accept an interface exposed by an entity set.

[vbray1979]

This is replicable on action as well. The following trigger the error message "Sequence contains more than one element" on "CreateWebHostBuilder(args).Build().Run();"

builder.EntityType<CsvTransactionModel>().Collection.Action("Upload");
builder.EntityType<CsvPriceModel>().Collection.Action("Upload");

This is working with Microsoft.AspNetCore.OData.Versioning v4.1.1

[benhysell]

Are all of the unit tests passing for everyone else? I was about to dig into this but kicked up three failed unit tests.

[benhysell]

I have a failing unit test in the example repo...I replicated my 'sloppy' cut and paste of MostExpensive to get odata_api_explorer_should_group_and_order_descriptions_on_providers_executed to fail. Latest code is pushed to the example repo.

Walking through the code, @commonsensesoftware, you are right, ln 244 var operation = EdmModel.FindBoundOperations( qualifiedName, entities[i] ).SingleOrDefault(); always falls through, throwing the exception on ln 252. Forgive my earlier post, still feeling my way around the project.

While fishing around the EdmModel I kick up two entries for MostExpensive, both with the same FullName field but differ by ReturnType. See attached screenshot.

I'm not able to step into EdmModel.FindBoundOperations, so I'm not sure what it is trying to do / how it is trying to resolve what it is looking for. The qaualifiedName is Default.MostExpensive

Any suggestions on how to further track this down?

[hasandogu]

We have updated OData versioning support to 5.0.0 and we seem to have an issue related with this. We have functions of the same name in a few of our entities and none of the paths were recognized (except one) for each function. All the other implementations using the same function name are ignored in Swagger and they return 404 when called. For instance, we have the following model and we can only call accounts/categories after upgrading. The others seem to be ignored

            builder.EntityType<AccountDto>().Collection
                .Function("Categories")
                .ReturnsCollection<AccountCategoryGroupingDto>();

            builder.EntityType<ProductDto>().Collection.Function("Categories")
                .ReturnsCollection<ProductCategoryGroupingDto>();

            builder.EntityType<SubscriptionDto>().Collection.Function("Categories")
                .ReturnsCollection<SubscriptionCategoryGroupingDto>();

They are however listed in metadata as bound functions. For instance:

            <Function Name="Categories" IsBound="true">
                <Parameter Name="bindingParameter" Type="Collection(Api.v1.Models.Dto.ProductDto)" />
                <ReturnType Type="Collection(Api.v1.Models.Dto.ProductCategoryGroupingDto)" />
            </Function>

Do you have any insight as to why this might be the case?

[cyril-iselin]

we are running into the same issue.

Also when I create a method like this:

[HttpGet] [ODataRoute( "GetAbc(Id={id},IncludeSubHistories={includeSubHistories})" )] [Produces( "application/json" )] [ProducesResponseType( typeof( Order ), Status200OK )] [ProducesResponseType( Status404NotFound )] [EnableQuery( AllowedQueryOptions = Select )] public Order GetAbc( [FromODataUri] int id, [FromODataUri] bool includeSubHistories ) { return new Order(); }

var config = builder.EntityType<Order>().Collection.Function( "GetAbc" ).Returns<Order>(); config.Parameter<int>( "Id" ); config.Parameter<bool>( "IncludeSubHistories" );

-> Swagger does not replace the parameters, it will get appended as querystring.
-> When I call the method manually, then I recive an odataexception :-(

[nokternol]

Subscribed to this issue as I am currently migrating an API from .net framework to .net5 and have hit this problem.
In our situation it is bound collection actions with the same name that is causing the issue.
Would appreciate any insight into a workaround why this is being resolved.

[engenb]

I've run into this issue as well.

This appears to be caused by a bug way down in the depths of Microsoft.OData.Edm, right here.

For some context, I created a quick sample to isolate this issue with two edm entity types Foo and Bar, each having a function Bulk

The line of code linked above is ultimately called by ODataRouteBuilderContext, from here

When we hit line 2528 of HasEquivalentBindingType, parameterType.TypeKind is EdmTypeKind.Collection while bindingType.TypeKind is EdmTypeKind.Entity. This results in this method immediately returning false on line 2530.

I do not know, but it looks like the special collection handling on line 2533 might need to be run first such as

if (parameterType.TypeKind == EdmTypeKind.Collection)
{
    // covariance applies here, so IEnumerable<A> is applicable to IEnumerable<B> where B:A
    IEdmCollectionType parameterCollectionType = (IEdmCollectionType)parameterType;
    IEdmCollectionType bindingCollectionType = (IEdmCollectionType)bindingType;

    return bindingCollectionType.ElementType.Definition.IsOrInheritsFrom(parameterCollectionType.ElementType.Definition);
}
else if (parameterType.TypeKind != bindingType.TypeKind)
{
    return false;
}
else
{
    return bindingType.IsOrInheritsFrom(parameterType);
}

or something along those lines. I should point out that the above code doesn't actually work because parameterType.TypeKind is Collection and bindingType does not implement IEdmCollectionType

@commonsensesoftware I don't know if it'd be more productive for you to communicate this issue with whoever maintains Microsoft.OData.Edm or if I should write up an issue against that repo.

Sample project can be found here

[engenb]

did some further testing. the following resolves the issue. I will write up a PR against Microsoft.OData.Edm.

if (parameterType.TypeKind == EdmTypeKind.Collection && bindingType.TypeKind == EdmTypeKind.Entity)
{
    var parameterCollectionType = (IEdmCollectionType)parameterType;
    return bindingType.IsOrInheritsFrom(parameterCollectionType.ElementType.Definition);
}

if (parameterType.TypeKind != bindingType.TypeKind)
{
    return false;
}

if (parameterType.TypeKind == EdmTypeKind.Collection)
{
    // covariance applies here, so IEnumerable<A> is applicable to IEnumerable<B> where B:A
    IEdmCollectionType parameterCollectionType = (IEdmCollectionType)parameterType;
    IEdmCollectionType bindingCollectionType = (IEdmCollectionType)bindingType;

    return bindingCollectionType.ElementType.Definition.IsOrInheritsFrom(parameterCollectionType.ElementType.Definition);
}
else
{
    return bindingType.IsOrInheritsFrom(parameterType);
}

@commonsensesoftware if you've got any pull with to grease the wheels to get this resolved, that'd be excellent. Hoping to not have to design around this bug.