mariiaKraievska commented on PR #6489:
URL: https://github.com/apache/fineract/pull/6489#issuecomment-6037467967

   > @mariiaKraievska Can you please review the below concerns?
   > 
   > 1. **The expensive check runs first** 
(`BuyDownFeeAmortizationStrategyServiceImpl.java:44`). 
`shouldRecognizeImmediately` looks up the product attribute before checking 
whether the loan is sold. The attribute lookup costs about three queries 
(product existence check, paged query, count query). That runs on every 
buy-down fee, adjustment and reversal for any open loan, even though most loans 
aren't sold. Checking `findActiveByLoanId(...).isPresent()` first would skip it 
in the common case.
   > 2. **One balance is found by loading all of them** 
(`LoanBuyDownFeeAmortizationProcessingServiceImpl.java:185`). 
`resolveRelatedBuyDownFeeBalance` loads every open balance on the loan and 
filters in memory by transaction id. A targeted repository method like 
`findByLoanIdAndLoanTransactionIdAndClosedFalse` would return the row directly. 
It must not filter on `deleted`, so that reversed fees are still found.
   > 3. **The attribute lookup is duplicated** 
(`BuyDownFeeAmortizationStrategyServiceImpl.java:48`). `isImmediateProduct` 
copies the lookup from `DelayedSettlementAttributeServiceImpl.isEnabled`. The 
copies already compare differently (`equals` vs `equalsIgnoreCase`). Both 
behave correctly today because stored values are always uppercase, but a shared 
helper on the read service would stop them drifting further.
   > 4. **Tests are missing.**
   >    
   >    * There are no unit tests for 
`BuyDownFeeAmortizationStrategyServiceImpl` or 
`processBuyDownFeeAmortizationImmediately`.
   >    * The branch that computes the amount from only the related balance 
(`useLoanWideAmortizedTotal=false`) has no unit test.
   >    * No end-to-end scenario reverses a buy-down fee _adjustment_ on a sold 
IMMEDIATE loan. That's the only new path with no test at all.
   > 
   > If anything here is worth holding the PR for, it's the missing 
adjustment-reversal scenario; the first three are optional cleanups.
   
   Thanks — addressed:
   
   1. Sold check before attribute lookup
   2. Targeted balance query (incl. deleted for reversals)
   3. Shared getAttributeValue on the read service
   4. Unit tests for the strategy service + e2e for adjustment reversal on sold 
IMMEDIATE


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to