UnitOfWorkCommandHandlerDecorator in UserAccess Module Doesn't Get Called.
See original GitHub issueHello Kamil,
I thought I have figured the project architecture from end to end and decided to try it out on a side project. I am almost sure I followed your example thoroughly and didn’t miss out anything. But when I tested it by trying out the RegisterUser
endpoint, It returns 200 but the user isn’t found at least in the database.
I tried to step through the process and realized that all through the process of the step-through, UnitOfWorkCommandHandlerDecorator
and ValidationCommandHandlerDecorator
were never called. When this line from CommandsExecutor.cs
runs - return await mediator.Send(command);
, Dispose()
of SqlConnectionFactory.cs
gets called next. I don’t know why this happens… At some point, the debug was stuck in between Quartz and SerilogLogProvider. I don’t know what I’m missing, and I’ve been on this for days.
I was hoping you would point me to the right direction because my frustration is building up.
Please help.
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (1 by maintainers)
Top GitHub Comments
@kacey90 I had a similar problem with the decorator and in my situation, there are a couple of problems.
The first problem is related to missing registrations of command handlers which are implements ICommandHandler<>. Thereby, MediatR resolved the IRequestHandler<> service from the container and my handlers were skipped. Another problem was in registering the decorator itself. You no need to set serviceType as
typeof(ICommandHandler<>)
, just change it to thetypeof(IRequestHandler<>)
. e.g.builder.RegisterGenericDecorator(typeof(UnitOfWorkCommandHandlerDecorator<>), typeof(IRequestHandler<>));
That new behavior with decorator registering was introduced in the Autofac starting from the v5. Kamil’s infrastructure project uses Autofac v4.9.2 where we have no such problems in registration. See details herecc @kgrzybek FYI
I’ve managed to do it like this (Autofac 6.2.0):