Arnold Galovics created FINERACT-2925:
-----------------------------------------
Summary: 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
✅ 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)
