[
https://issues.apache.org/jira/browse/FINERACT-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandar Vidakovic updated FINERACT-2661:
-------------------------------------------
Priority: Minor (was: Major)
> Prevent application runtime failures by validating and handling duplicate
> CommandHandlers in DefaultCommandHandlerManager
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2661
> URL: https://issues.apache.org/jira/browse/FINERACT-2661
> Project: Apache Fineract
> Issue Type: Bug
> Components: System
> Reporter: Atharva Kamat
> Priority: Minor
> Fix For: 1.15.0
>
> Attachments: Screenshot 2026-06-26 002307.png
>
>
> Description
> Currently, in DefaultCommandHandlerManager.java, the lookup() method utilizes
> .findFirst() when resolving a handler for an incoming command.
> The Problem:
> If multiple handlers inadvertently match the same command, the system will
> silently pick the first one it encounters. This leads to unpredictable
> runtime bugs, silent failures, and makes debugging extremely difficult as the
> behavior depends entirely on the non-guaranteed order of the injected
> handlers list.
> There is already an existing
> // TODO: make sure there are no duplicate handlers
> comment in the codebase acknowledging this risk.
>
> Proposed Solutions
> Option A (at Runtime): Update the lookup method to collect all matching
> handlers into a list. If matchingHandlers.size() > 1, log an error and throw
> new DuplicateCommandHandlerException(command).
> Option B (at Startup): Implement a @PostConstruct validation method that
> checks the injected List<CommandHandler> handlers for duplicate command
> mappings right when the Spring context initializes and throw the
> DuplicateCommandHandlerException. We have 1:1 mappings for handler:command
> class.
>
> Option B feels intuitive to me because the application will fail to boot if a
> dev introduces a duplicate handler.
> Please guide me which approach is better. I would like to work on that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)