[
https://issues.apache.org/jira/browse/FINERACT-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Saghy resolved FINERACT-2925.
----------------------------------
Resolution: Fixed
> Start COB catch-up after a replayed Loan COB or Working Capital COB run
> -----------------------------------------------------------------------
>
> Key: FINERACT-2925
> URL: https://issues.apache.org/jira/browse/FINERACT-2925
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Arnold Galovics
> Assignee: Arnold Galovics
> Priority: Major
> Fix For: 1.16.0
>
>
> ✅ Acceptance Criteria
> • With fineract.job.execute-missed-runs on, when a Loan COB run finishes
> COMPLETED and loans are lagging, the existing catch-up
> (COBCatchUpExecutorHelper, the same path as /loans/catch-up) starts and the
> loans reach the current COB date. On a normal night nothing extra starts.
> • Working Capital COB behaves the same.
> • Ordering: a Liquibase changeset puts the business date, COB date, Loan COB
> and Working Capital COB jobs in one scheduler_group greater than 0 (single
> thread), and ScheduledJobDetailRepository#findAllJobs orders by task_priority
> desc, id. A unit test with real in-memory Quartz asserts the replayed
> business-date runs happen before COB.
> • Unit tests for the listener cover: flag off, job not COMPLETED, catch-up
> already running, lagging versus up to date.
> • The grouping is documented in batch-jobs.adoc.
>
> 📘 Background
> • A regular Loan COB run only picks loans with last_closed_business_date =
> COB_DATE-1 or NULL (RetrieveAllNonClosedIdServiceImpl), so one replayed run
> leaves loans that are more than one day behind still lagging.
> • Catch-up (AsyncCommonCOBExecutorService) runs one COB per lagging day and
> reads COB_DATE once when it starts. If it starts before the business date has
> caught up, it stops at the old date.
> • Seed data puts every job in scheduler_group 0, the shared 7-thread tenant
> pool, so business date and COB run concurrently. task_priority does not
> serialize them, and inside a single-thread group the order comes from
> nextFireTime with priority only breaking ties.
>
> ℹ️ Notes
> • Depends on the missed-runs ticket for the flag.
> • With the flag on, the helper's unlockHardLockedLoans() releases loans that
> failed COB and they are retried every night. One stuck old loan makes
> catch-up iterate every day since its date.
> • A shared group serializes Loan COB and Working Capital COB and delays the
> next midnight fires. The business-date job still fires each missed date
> (IGNORE policy).
> • The changeset changes the default scheduler_group for every deployment;
> open to a documentation-only alternative if reviewers prefer.
>
> 🔧 Technical Notes
> • Hook: an after-job listener (FineractCOBAfterJobListener, one subclass each
> for Loan COB and Working Capital COB, in the cob.listener package,
> conditional like the catch-up services) calling COBCatchUpExecutorHelper
> unchanged when the flag is on and the execution is COMPLETED. After a regular
> run, loans that were one day behind are at COB_DATE, so catch-up only starts
> for loans genuinely behind, and the regular run has finished so they do not
> overlap.
> • Rejected: a before-job hook. The helper starts catch-up whenever the oldest
> loan date is not COB_DATE, which is the normal state at the start of a
> nightly run, and IS_CATCH_UP is not yet in the execution context at beforeJob.
> • Recursion is not possible: while a catch-up run's afterJob executes its row
> is still STARTED, so isCatchUpRunning() is true and the helper answers 400.
> • Fallback if the async hook proves racy: a synchronous before-hook that
> catches up to COB_DATE-1, skipping catch-up runs through isCatchUpRunning().
> • To confirm by a local run: replay-then-COB order with real fires in one
> group, and Working Capital COB behaving the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
