[
https://issues.apache.org/jira/browse/FINERACT-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashhar Ahmad Khan updated FINERACT-2786:
----------------------------------------
Fix Version/s: 1.16.0
> EmailMessage.pendingEmail() throws NullPointerException on /v1/email CREATE
> due to hardcoded null emailCampaign
> ---------------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2786
> URL: https://issues.apache.org/jira/browse/FINERACT-2786
> Project: Apache Fineract
> Issue Type: Bug
> Reporter: Ashhar Ahmad Khan
> Priority: Minor
> Fix For: 1.16.0
>
>
> What is broken
> EmailMessageAssembler.assembleFromJson(), the method that builds an
> EmailMessage from a /v1/email CREATE request, calls
> EmailMessage.pendingEmail(group, client, staff, null, emailSubject, message,
> emailAddress, null), passing emailCampaign as a hardcoded null.
> pendingEmail()'s body unconditionally calls
> .setStatusType(emailCampaign.getStatus()) with no null check, so it throws
> NullPointerException on every single /v1/email CREATE request, regardless of
> which valid fields are supplied. This makes /v1/email CREATE completely
> unusable today, independent of and in addition to the validator bug fixed in
> FINERACT-2785.
> Why it's broken
> Runtime confirmed with a Mockito test calling assembleFromJson() with a valid
> clientId and emailMessage payload. The call throws NullPointerException from
> inside pendingEmail(), not from anywhere in EmailMessageAssembler itself.
> Grepped every caller of pendingEmail() across the codebase. Found three other
> call sites, two in EmailCampaignWritePlatformCommandHandlerImpl and one in
> UpdateEmailOutboundWithCampaignMessageTasklet, and all three always pass a
> real, non-null EmailCampaign. The /v1/email assembler is the only caller that
> passes null. The email_campaign_id column itself is nullable at the JPA/DB
> level, confirming the schema always intended campaign-less emails to be
> valid. pendingEmail() was just never written to handle that case because
> nothing called it that way until /v1/email's assembler was added.
> EmailMessage.java already contains a second factory method, instance(),
> sitting right next to pendingEmail(), which takes statusType as an explicit
> parameter instead of deriving it from emailCampaign.getStatus(), so it is
> null safe by construction. Grep confirms zero production callers currently
> used instance() before this fix, it was dead code with the right shape, not
> an established pattern.
> Changes made
> * EmailMessageAssembler.assembleFromJson() now calls
> EmailMessage.instance(group, client, staff, null,
> EmailMessageStatusType.PENDING, emailSubject, message, null, emailAddress,
> null) instead of pendingEmail(...). This required zero changes to
> EmailMessage.java itself, so it carries zero risk to the three working
> campaign driven callers of pendingEmail().
> * Added EmailMessageAssemblerTest.java, a regression test confirming
> assembleFromJson() no longer throws and produces a PENDING EmailMessage when
> only clientId is supplied.
> Related
> FINERACT-2785 (validator fix, separate bug, same resource, found during the
> same investigation)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
