[
https://issues.apache.org/jira/browse/FINERACT-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashhar Ahmad Khan updated FINERACT-2804:
----------------------------------------
Affects Version/s: 1.16.0
> IndexOutOfBoundsException in SavingsAccountAssembler when no transactions
> exist after relaxed pivot date
> --------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2804
> URL: https://issues.apache.org/jira/browse/FINERACT-2804
> Project: Apache Fineract
> Issue Type: Bug
> Affects Versions: 1.16.0
> Reporter: Ashhar Ahmad Khan
> Priority: Minor
>
> *What is broken*
> SavingsAccountAssembler.loadTransactionsToSavingsAccount(), the method that
> loads a savings account's transactions before any write action (deposit,
> withdrawal, and so on), calls
> savingsAccountTransactions.get(0).getSavingsAccount().setStartInterestCalculationDate(...)
> with no check that the list returned by findTransactionsAfterPivotDate() is
> non-empty. This code path only runs when the relaxing days pivot date config
> (allow-backdated-transaction-before-interest-posting-date-for-days) is
> enabled. If an account has zero transactions after the relaxed pivot date
> window, for example a dormant account or one where every transaction falls
> before the window, this throws IndexOutOfBoundsException on every write
> action that assembles the account, including a plain deposit.
> *Why it's broken*
> The running balance update logic in this method was refactored in 2022 to
> move the running balance calculation out of a block further down in the same
> method, one that was already properly guarded with savingsAccountTransactions
> != null && !savingsAccountTransactions.isEmpty(). That refactor introduced
> the new, unguarded get(0) access a few lines above the existing guarded
> block, and the guard was never carried over to the new access point.
> Confirmed with a Mockito test calling loadTransactionsToSavingsAccount() with
> the relaxing days config enabled and findTransactionsAfterPivotDate() mocked
> to return an empty list, which throws IndexOutOfBoundsException from the
> unguarded block.
> *Changes made*
> SavingsAccountAssembler.loadTransactionsToSavingsAccount() now wraps the
> savingsAccountTransactions.get(0) access in the same null and empty check
> already used later in the method, so the method falls through safely when
> there are no transactions in the relaxed pivot window.
> Added SavingsAccountAssemblerTest.java, a regression test confirming
> loadTransactionsToSavingsAccount() no longer throws when the relaxing days
> config is enabled and no transactions exist after the pivot date.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
