What would be the preferred way to prevent missing Aggr Identifier exception?

I have some cases where not satisfied invariants causes the command handler to abort without handling the event source which causes the following error:

Command 'com.acme.MyCommand' resulted in
must be set after handling the message)

This is not causing any issue on my business logic but having an exception affects my metrics (commandBus.failureCounter) producing false positives

What would be the proper approach to prevent this exception to happen?

aggregate snippet implementation

  public void on(MyCommand command) {

  private Optional<MyEvent> ensureInvariants(MyCommand command) {
    if (command.getAlarm().isExpired()) {
      log.warn("An active alarm is expected! Alarm id={}", 
      return Optional.empty();

  return Optional.of(new MyEvent());

Axon Config:

  • SimpleCommandBus
  • MongoEventStoreEngine

Typically a method like ensureInvariants should have a void return type, and throw an exception, extending the AxonException. I’m not sure that would change something for the error rate, bit the error would more clear.

Yes I also guess that throwing an exception will end up in the same behavior.

It will cause a command error which is not the desire when the invariants are not met.

I would expect something like: “The aggregate validates the invariants, when not satisfied it should abort without any side-effect”.

I can see two distinct situations: 1) invariant not fulfilled silent abort 2) invalid invariant throw a meaningful exception

Nothing exceptionally had happened but also the process should not proceed because does not fulfill the expected requirements.

An ugly solution for that would be a meaningless event like e.g. AggregateCreated which would hydrate the aggregate identifier in the @EventSourcingHandler but has no side-effect, just to prevent the undesired exception

PS:. I am wondering if such question fits better here on in the Architectural Concepts forum

You could add an error handler that just logs, or even does nothing, in the case that it’s a expected domain exception. I think that should prevent it from showing up in the metrics.

hey @habutre,

Isn’t it a ‘bug’ fixed on this PR?

To make sure it works (and the Exception is not thrown), you can use the SNAPSHOT version.