No error/warning for duplicate command handler

[azzazzel]

Basic information

• Axon Framework version: 4.5
• JDK version: 1.8 (but likely not relevant)
• Complete executable reproducer if available (e.g. GitHub Repo): https://gist.github.com/azzazzel/3f4cee7a3fc7c5193fcfbf01a8688f65

Steps to reproduce

Create an Aggregate that handles the same command in a constructor and in a method:

@CommandHandler
public MyAggregate(MyCommand myCommand) {
   ...
}

@CommandHandler
public void update(MyCommand myCommand) {
   ...
}

and start the application.

Expected behaviour

The framework prints "A duplicate command handler was found for command ... " error / warning message

Actual behaviour

No information about the duplicate handler

[leechedan]

@smcvb @azzazzel well, is just logging in warn is ok in this scene? or when should open the window like DuplicateCommandHandlerResolver

[smcvb]

I'd wager the DuplicateCommandHandlerResolver would be an ideal solution in this case too.
The default instance would indeed log, as throwing an exception out of the dark right now is definitely a breaking change.

[leechedan]

I'd wager the DuplicateCommandHandlerResolver would be an ideal solution in this case too.
The default instance would indeed log, as throwing an exception out of the dark right now is definitely a breaking change.

well, how about the name of DuplicateCommandHandlingMemberResolver

[smcvb]

Although technically the same, conceptually a Command Handler can only exist at one spot. Otherwise, there's no guarantee that there's a single aggregate or component that is in charge of the command.

So the current class is called DuplicateCommandHandlerResolver to closely align with that conceptual point.

Added, renaming DuplicateCommandHandlerResolver to DuplicateCommandHandlingMemberResolver would be a breaking change at this point in time. As such it is not something we can do for Axon version 4.x. As soon as we start with Axon 5 we would be able to do.

[leechedan]

i mean create a new DuplicateCommandHandlingMemberResolver interface and configure bean in AxonAutoConfiguration

[smcvb]

i mean create a new DuplicateCommandHandlingMemberResolver interface and configure bean in AxonAutoConfiguration

Gotcha. I do not think it makes sense to construct an identical class as the DuplicateCommandHandlerResolver. Or, another object that serves the same purpose for that matter.
It's best to reuse DuplicateCommandHandlerResolver as that is exactly the problem that needs to be resolved on the Aggregate.

[smcvb]

Note that the solution for this problem is threefold:

1. In the AnnotatedAggregateModel, log if there is another command handler with the same name.
2. In the AnnotatedAggregateModel, throw an AggregateModellingException if there are two command handlers with the same name and set of parameters (as this does indicate a duplicate).
3. Expand the test fixtures to validate duplicate command handlers within the Aggregate under test.

So, not direct reuse or copy of the DuplicateCommandHandlerResolver, but a different way to tackle the situation.
This follows from the requirement that an Aggregate can have two Command Handlers for the same command, which can be fine given the parameters are different.
Two (or more) command handlers with the same command name but different resolvable parameters can be a form to switch between different handling solutions based on metadata, for example.
As this is currently supported, that should stay within the framework.

[smcvb]

We consider this not as a bug, but as an enhancement over the current solution.
Since we prefer enhancements and features for minor releases, we adjusted the milestone of this issue to 4.6.0.

[smcvb]

Closing this issue as it's resolved in pull request #2207.