Abhishek Chaudhary created FINERACT-2915:
--------------------------------------------
Summary: Recalculate Interest For Loans job skips loans because
its paging cursor advances by page size
Key: FINERACT-2915
URL: https://issues.apache.org/jira/browse/FINERACT-2915
Project: Apache Fineract
Issue Type: Bug
Components: Job Scheduler, Loan
Affects Versions: 1.15.0
Reporter: Abhishek Chaudhary
Fix For: 1.16.0
When the job runs with an {{officeId}} parameter,
{{RecalculateInterestForLoanTasklet}} pages through loans with
{{maxLoanIdInList += pageSize + 1}}. That moves the cursor by a fixed number of
ids, not to the last loan id fetched. The query
({{fetchLoansForInterestRecalculation}}) selects {{l.id >= ? ... GROUP BY l.id
LIMIT ?}} with no {{ORDER BY}}.
This is the default setup: job 17 is seeded with {{officeId=1}},
{{thread-pool-size=10}} and {{batch-size=100}}, which gives a page size of 1000.
* *Rows in id order:* with 5000 consecutive eligible loans, pages cover 1-1000,
1001-2000, then 2002-3001. Loans 2001, 3002 and 4003 are never recalculated,
and the same loans are skipped on every run.
* *Rows in arbitrary order:* without {{ORDER BY}}, PostgreSQL may return the
grouped rows in any order. Any unprocessed loan below the cursor is then
skipped.
* *Floating-rate loans* are not excluded once recalculated, so they can be
processed more than once in a run.
*Expected:* page by the last fetched loan id ({{l.id > ?}}) and order the query
by {{l.id}}, as
{{SavingsAccountReadPlatformServiceImpl.getAccountsIdsByStatusPaged}} already
does.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
