Atharva Kamat created FINERACT-2661:
---------------------------------------
Summary: 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
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)
