Random VerificationException/TypeLoadException

[dario-hd]

We have a .NET 6 application exposing APIs and we are building dynamic proxies around all controllers and also around almost all services. Everything works fine, but we experience some issues when we deploy our application to production. The application is containerized and during deployment, which stops some old containers and starts new containers progressively, it randomly throws the following exception for some random methods:

System.Security.VerificationException: Method IEntityResolver.ResolveAsync: type argument 'TResult' violates the constraint of type parameter 'TEntity'.
   at Castle.Proxies.Invocations.IEntityResolver_ResolveAsync_3.InvokeMethodOnTarget()
   at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at Castle.DynamicProxy.AbstractInvocation.ProceedInfo.Invoke()
   at Castle.DynamicProxy.AsyncInterceptorBase.ProceedAsynchronous[TResult](IInvocation invocation, IInvocationProceedInfo proceedInfo)

The thing is that this doesn't happen all the time and it never happens locally or on our CI. Recently, this is happening very frequently, almost at every deployment, which is quite frequent. The thing that is changing in this regard might be the number of requests our APIs receive, which is constantly increasing.

To give some more details, here's the definition of the interface IEntityResolver:

public interface IEntityResolver
    {
        Task<long> ResolveAsync<TEntity>(string entityId)
            where TEntity : BaseEntity, IHasEntityIdEntity;
    }

Apparently, there's nothing wrong with the definition of the interfaces and their usages since stopping the container throwing the exceptions and starting a new one works most of the time. Also, such methods are used very frequently in our application from all containers.

I've been thinking to catch this exception and add some more info to the logs, but I'm not sure if we would be able to get something useful out of them.

In the meanwhile, does anyone have any ideas on how to track this down? Does anyone else experience this? Does anyone have an idea what could be the issue?

[stakx]

This might be really difficult, if not impossible, to figure out, especially without a minimally complete and verifiable code example for reproduction.

System.Security.VerificationException: Method IEntityResolver.ResolveAsync: type argument 'TResult' violates the constraint of type parameter 'TEntity'.

Where does TResult come from? And do you have any way of figuring out exactly what concrete type TResult is? Is it possible that you are providing an incompatible type argument (say, via Reflection), and the bug is in fact not in DynamicProxy or the CoreCLR, but in your own code?

[dario-hd]

@stakx thanks a lot for the answer! That's true, this looks like a challenge!

Interestingly enough, TResult is not involved in this interface as well as in the implementation of the interface. BUT, we have other classes with such argument.

If there would be a bug I would expect the exception to be thrown quite consistently and stopping the "fault" container and stating a new one would not fix the issue, or? It seems that there is something wrong going on at startup somehow.

As mentioned previously, we will try to figure out more, but in the meanwhile, I thought of posting it here. Maybe nothing is wrong in Castle.Core and Autofac is doing something out of our control? To be figured out.

[maxcherednik]

Similar issue here: FakeItEasy/FakeItEasy#1910 (comment)

So far I managed to see the pattern in failing. When it fails, the method definition of the generated type looks different from the interface.

[gokhanabatay]

Hi @stakx
We have the same issue with castle core dynamic proxy.

System.TypeLoadException: GenericArguments[0], 'T', on 'Castle.Proxies.Invocations.IProfileMapService_AssingProfile[T]' violates the constraint of type parameter 'T'.
   at Castle.Proxies.IProfileMapServiceProxy.AssingProfile[T](AssignProfileRequest assignProfileRequest)

  at Castle.DynamicProxy.AbstractInvocation.Proceed()
   at lambda_method17752(Closure , Object , Object[] )
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncActionResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|26_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)

public interface IProfile
{
    string Code { get; set; }
}

public class FeeProfile : IProfile
{
    public string Code { get; set; }
}

public class AssignProfileRequest
{
    public virtual string AccountNo { get; set; }

    public virtual string ProfileCode { get; set; }
}

public interface IProfileMapService 
{
    void AssingProfile<T>(AssignProfileRequest assignProfileRequest) where T : IProfile;
}

public class ProfileMapService : IProfileMapService
{
    public void AssingProfile<T>(AssignProfileRequest assignProfileRequest) where T : IProfile
    {
         //Query type T entity, assign profile to member
    }
}

[stakx]

@gokhanabatay – same in your case, without a minimally complete and verifiable code example that actually reproduces the exception, there's not much we can do.

[tpflueger]

@stakx - I have created a reproduction of the random VerificationException located here. It might take a couple runs but it should error out.