Duplicate query-handlers


As pointed out in this post, when you define two query-handlers with the same signature in the same class, only one (we figured out, the one alphabetically first) is being used.
I do understand the mentioned history of why this is, and that changing it might be impactful.
However, wouldn’t it be helpful in this case to have some kind of fail fast, instead of trying to figure out how this is actually working?
More or less in line with a Spring boot application failing to start when there are config issues.

Hello and welcome to AxonIQ community @parcival,

I recently found somewhat similar issue with command handlers which resulted in this issue:

No error/warning for duplicate command handler · Issue #1756 · AxonFramework/AxonFramework · GitHub.

I believe it’ll be OK to open similar issue for the case you’ve found. I can’t make any promises about the resolution and the timeframe but I agree with you - it would be nice to inform the user about the situation. I would argue that a warning message is more suitable in this case. Preventing the application from starting seems too restrictive to me.

That said and taking into account @allardbz’s comment about scatter-gather queries:

We might want to reconsider the behavior in that case

it may not be as straightforward as it seems. If we are to allow “duplicate” query handlers for scatter-gather queries (which I personally think is a good feature) than I guess we’ll have to allow them in general. AFAIK it’ll be next to impossible to know (at the time when query handling components are registered) how a particular query handling method will be used. That would probably render the warning we discus here useless. It would also require some other means (for example adding priority attribute to @QueryHandler) do decide which of the “duplicate” query handlers to execute for direct and subscription queries.

Perhaps @Steven_van_Beelen can tell which approach makes more sense and/or is better aligned with framework’s roadmap.

Nice for pointing me at a similar issue, @milendyankov. I do think it is just the same logic being applied internally in Axon that results in that same behavior. Will add a new issue referring to yours.

There actually already is an issue on the matter, which you can find here.
At the time of inception of the QueryBus, we quite early on noticed the problem too.

I’d wager the desired approach should be configurable for the users, as opposed to silently swallowing the fact your query handler is overwritten. For Command Handlers the behaviour is configurable, so it would make sense to allow a similar approach, albeit with likely different defaults, reasonable.

The planning meeting for 4.6.0 of AF is coming quite soon, so I’ll take this issue into considerations at that moment in time. Thanks for bringing it back to mind @parcival.
I’ll make sure to update this thread when a decision is made on #719.

1 Like