expandable nav property on model ignored in AutoMapper profile causes exception

[engenb]

Hey there,

Hoping this is the most appropriate place to start the conversation between this repo and AutoMapper.Extensions.ExpressionMapping!

I'm doing something probably a bit outside the norm. I'm aggregating two datasources behind an OData API. My database has Users and each User has its respective Identity in Azure B2C.

Currently, my application fetches Users from an OData API and then will separately fetch the Identity from B2C using the resulting User's IdentityId. I'd like to update my API to abstract B2C away from my application and add Identity to my User model. This would allow my application to request a User and optionally include its Identity with $expand=Identity and the details of how or where that Identity comes from can be a concern of the User API.

So, imagine this pretty slimmed-down example of my model:

• Model.Identity - OOdata model (first/last name, email, etc)
• Microsoft.Graph.User - record in B2C via graph API, mapped to Model.Identity
• Model.User - OData model, has a Model.Identity, roles, tenant assignment, other customer-specific stuff
• Entity.User - EFCore entity mapped to Model.User

AutoMapper profile:

CreateMap<Entity.User, Model.User>()
    .ForMember(dest => dest.Id, opts => opts.MapFrom(src => src.Id))
    .ForMember(dest => dest.IdentityId, opts => opts.MapFrom(src => src.IdentityId))
    .ForMember(dest => dest.Identity, opts => opts.Ignore());

My OData model:

var builder = new ODataConventionModelBuilder();
var set = builder.EntitySet<Model.User>("Users");
var type = set.EntityType;
type.HasKey(x => x.Id);
type.HasRequired(x => x.Identity);

In my controller I might do something like:

public async Task<IActionResult> Get(ODataQueryOptions<Model.User> queryOptions)
{
    var users = await dbContext.Users
        .AsNoTracking()
        .GetAsync(mapper, queryOptions);
    
    var expands = queryOptions.SelectExpand.GetExpansions(typeof(Model.User));
    if (expands.Contains($"{nameof(Model.User.Identity)}"))
    {
          // bulk fetch identities from B2C with user.IdentityIds
          // and assign to users
    }

    return Ok(users);
}

And yes, I'm definitely thinking about the complexity this can open up, if clients ever want to query for Users and then do something like $filter=Identity/Email eq 'whatever' but just including the Identity as a starting point and not worrying about supporting $filter would be a big win here.

When I run a query with the above setup and specify $expand=Identity I get an error:

System.InvalidOperationException: SourceMember cannot be null. Source Type: User, Destination Type: User, Property: Identity.
   at AutoMapper.Extensions.ExpressionMapping.XpressionMapperVisitor.FindDestinationFullName(Type typeSource, Type typeDestination, String sourceFullName, List`1 propertyMapInfoList)
   at AutoMapper.Extensions.ExpressionMapping.MapIncludesVisitor.<VisitMember>g__GetMappedMemberExpression|2_0(Expression parentExpression, List`1 propertyMapInfoList, <>c__DisplayClass2_0& )
   at AutoMapper.Extensions.ExpressionMapping.MapIncludesVisitor.VisitMember(MemberExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
   at AutoMapper.Extensions.ExpressionMapping.MapIncludesVisitor.VisitLambda[T](Expression`1 node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
   at AutoMapper.Extensions.ExpressionMapping.XpressionMapperVisitor.VisitUnary(UnaryExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
   at AutoMapper.Extensions.ExpressionMapping.XpressionMapperVisitor.<>c__DisplayClass38_0.<VisitMethodCall>b__0(List`1 lst, Expression next)
   at System.Linq.Enumerable.Aggregate[TSource,TAccumulate](IEnumerable`1 source, TAccumulate seed, Func`3 func)
   at AutoMapper.Extensions.ExpressionMapping.XpressionMapperVisitor.VisitMethodCall(MethodCallExpression node)
   at System.Linq.Expressions.ExpressionVisitor.Visit(Expression node)
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.<MapExpression>g__MapBody|8_1[TDestDelegate](Dictionary`2 typeMappings, XpressionMapperVisitor visitor, <>c__DisplayClass8_0`1& )
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.<MapExpression>g__CreateVisitor|8_0[TDestDelegate](Dictionary`2 typeMappings, <>c__DisplayClass8_0`1& )
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.MapExpression[TDestDelegate](IConfigurationProvider configurationProvider, LambdaExpression expression, Type typeSourceFunc, Type typeDestFunc, Func`3 getVisitor, Func`2 shouldConvertMappedBodyToDestType)
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.MapExpression[TDestDelegate](IMapper mapper, LambdaExpression expression, Func`3 getVisitor, Func`2 shouldConvertMappedBodyToDestType)
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.MapExpressionAsInclude[TDestDelegate](IMapper mapper, LambdaExpression expression)
   at System.Linq.Enumerable.SelectEnumerableIterator`2.ToList()
   at AutoMapper.Extensions.ExpressionMapping.MapperExtensions.MapIncludesList[TDestDelegate](IMapper mapper, IEnumerable`1 collection)
   at AutoMapper.AspNet.OData.QueryableExtensions.GetDataQuery[TModel,TData](IQueryable`1 query, IMapper mapper, Expression`1 filter, Expression`1 queryFunc, ICollection`1 includeProperties)
   at AutoMapper.AspNet.OData.QueryableExtensions.GetAsync[TModel,TData](IQueryable`1 query, IMapper mapper, Expression`1 filter, Expression`1 queryFunc, ICollection`1 includeProperties, AsyncSettings asyncSettings)
   at AutoMapper.AspNet.OData.QueryableExtensions.GetAsync[TModel,TData](IQueryable`1 query, IMapper mapper, ODataQueryOptions`1 options, QuerySettings querySettings)

My expected (desired) behavior would be for AutoMapper to ignore the Model.User.Identity property and not try to map it to an include statement when generating the expression for EF Core.

Not sure if I'm relating the right section of the docs, but I thought Ignore would be a supported operation Maybe that's only respected for simple properties and not navigation properties and/or when generating .Include(...) statements? Just wondering if I can configure things differently or if someone can provide some insight into what I'm seeing.

Thanks!

[BlaiseD]

May be make the problem more narrow.

If your configuration is:

CreateMap<Entity.User, Model.User>()
                .ForMember(dest => dest.Id, opts => opts.MapFrom(src => src.Id))
                .ForMember(dest => dest.IdentityId, opts => opts.MapFrom(src => src.IdentityId))
                .ForMember(dest => dest.Identity, opts => opts.Ignore());

What should be the result from mapping this expression Expression<Func<Model.User, object>> selection = s => s.Identity;?

I think Ignore() is used to validate that missing maps are intentionally missing.

Make sense?

[engenb]

Yup, makes sense. I can understand that .Ignore() must just omit that property from any profile validation and may not be considered if an explicit mapping operation is done as you showed above. If the expression mapping returned null in this case I think it'd work with the OData extensions for ExpressionMapping, but I think this behavior would be a bit odd in general.

If it's not possible to inspect IMapper's registered profiles for if a relevant property is explicitly ignored, is there another way? Really what I'm looking for, is a way to tell the OData extensions for ExpressionMapping, "don't try to handle this/these properties, they're not in the database. I'll take over responsibility" Could something be added to QuerySettings to indicate model properties to omit from any expression mapping?

[BlaiseD]

It sounds like you want the URL to indicate expansion but for the library to ignore it? Then you probably need to create your own extension methods to do this without the includes (or even earlier).

I think it would be an odd use case to add to the library.

[engenb]

Yes, something like that would meet my need. I'll see if I can get in the middle and filter out that include.

[engenb]

I think I'll definitely be able to do what I need with my own GetUsersAsync adapted from GetAsync. Would you consider making ApplyOptionsAsync public? I can call it with reflection if I really have to, but I don't see another way with what's currently exposed to me.

[BlaiseD]

Sure - go for it.