The active Unit of Work is expected to contain a CommandMessage or a DeadlineMessage

Axon Framework
1

We are upgrading Axon framework 4.6.8 to 4.8.2 and we now have a situation where our logs spam warning message about “The active Unit of Work is expected to contain a CommandMessage or a DeadlineMessage, but instead contains a [class org.axonframework.eventhandling.GenericTrackedDomainEventMessage]”

We checked the source for this and tracked it into https://github.com/AxonFramework/AxonFramework/blob/e2f3e235e839230848316e00cbb5fa8225a444b5/modelling/src/main/java/org/axonframework/modelling/command/AbstractRepository.java#L199C26-L199C110

Could you elaborate what might be the problem and why the warning is raised? It seems that the implementation just warns about this and returns the current unit of work as it is. We do not experience any problems handling the events even though the warning message is printed on our logs.

Thank you.

2

Hi @nikortel,

I wonder how the EventMessage would end up in the UnitOfWork used by the aggregate repository. We previously removed the warning for deadlines, which can be set on the UnitOfWork. There might be a valid reason to EventMessage ends up there, and we may need to exclude it as well. But since I didn’t hear about this issue before, I wonder if something is happening in the aggregate we might not have accounted for.

3

Hi Gerard and thanks for quick reply. We are maintaining an service that is build on Axon and we have noticed quite weird usage of the framework, so…

Could this have something to do about loading an aggregate from aggregate repository directly? There is a code which loads one of our aggregates from repository that is set up like so:

EventSourcingRepository.builder(OurAggregate.class)
                        .eventStore(eventStore)
                        .build();

This is something we think should not be done but that is what is currently in the code. We are suspecting loading has something to do with it as the warnings are generated for the functionality that is using the direct loading.

4

Hi @nikortel, and welcome to our forum!

The warn message is intended to signal users that they may be using Repository from an unexpected piece of code.
Note that the Repository in Axon Framework is a solution intended to be invoked by (1) Command Handlers and (2) Deadline Handlers.

Axon Framework’s annotated-model approach (read: @CommandHandler and @DeadlineHandler annotations on the Aggregate class) ensures you a CommandMessage or DeadlineMessage is in the active UnitOfWork.
Furthermore, direct use of the Repository from within an @CommandHandler annotated method outside the model ensure this too, as Axon set’s a UnitOfWork containing the message that’s being handled at all times.

If you, however, invoke the Repository from other locations, there’s a chance that you either (1) don’t have a UnitOfWork at all or (2) are in the scope of another type of Message.
Scenario one may occur when you are, for example, invoking the Repository directly from a POST endpoint. So, without having dispatched a command/event/query or without having manually set a UnitOfWork.

Scenario two, the one I assume you are in, occurs whenever you invoke the Repository from an @EventHandler, @QueryHandler, or @ExceptionHandler (as shown in this issue, which led to the introduction of the WARN-level log message) annotated method.

So, to conclude, as Axon Framework expects invocations of the Repository to occur through command and deadline handlers, we warn the user when this is not the case.
As in your scenario the logging states a GenericTrackedDomainEventMessage is present, that to me suggests your code invokes the Repository within an @EventHandler annotated method.

Although I don’t know the full extend of your application, I do want to point out that this is thus not the default behavior of Axon Framework (hence the logging. The Repository and it’s aggregates are used for decision-making logic, through command dispatching. It being invoked in an event handler suggests it may be used to query the state of the aggregate, which is typically not the purpose of the Command Model.

Granted, if you and the team decided against the combination of CQRS and DDD (in short, a dedicated domain model for command validation), there isn’t anything wrong.
If you do prefer to use the combination of DDD and CQRS by the book, I would suggest to not query the command model Repository directly, every.

By the way, I am making an assumption that you are directly invoking the Repository in an @EventHandler annotated method. If that’s not the case, we need to investigate further.

I hope this clarifies things for you, @nikortel!

1 Like
5

That seems quite possible. As it’s just a warning, I guess it’s fine. Of course, you can configure your logging to no longer get the warning. Fixing the root cause will likely be more difficult. The warning was introduced in 4.7.2, and doesn’t influence it’s working.

6

Hi Steven, this is exactly the scenario 2. The aggregate is loaded inside an event handler. Thank you for the clarification.

We need to think about how we can remove the need for the aggregate loading as we are painfully aware, this is not a good thing.

But I think this satisfies this discussion.

Thanks again!

1 Like