[jira] [Created] (FINERACT-2918) Scheduler resume replays misfired jobs asynchronously, then saves a future next_run_time, so the replay vetoes itself

["Arnold Galovics (Jira)" <ji...@apache.org>]

Arnold Galovics created FINERACT-2918:
-----------------------------------------

             Summary: Scheduler resume replays misfired jobs asynchronously, then saves a future next_run_time, so the replay vetoes itself
                 Key: FINERACT-2918
                 URL: https://issues.apache.org/jira/browse/FINERACT-2918
             Project: Apache Fineract
          Issue Type: Bug
            Reporter: Arnold Galovics
            Assignee: Arnold Galovics


📋 JIRA Bug Preview 1/5
─────────────────────────────────────
Project:   FINERACT - Apache Fineract
Type:      Bug
Summary:   Scheduler resume replays misfired jobs asynchronously, then saves a future next_run_time, so the replay vetoes itself

🐛 Steps to Reproduce
  1. Fineract 1.15.0 (or develop), scheduler_detail.execute_misfired_jobs = true (the default).
  2. Give an active job a 1-minute cron (e.g. Update Loan Arrears Ageing).
  3. POST /scheduler?command=stop.
  4. Wait for a few cron fires, so the job has is_misfired = true.
  5. POST /scheduler?command=start.
  6. Check the job run history and the next_run_time / is_misfired columns of the job.

❌ Actual Result
  • The replay is vetoed and the job does not run (ran in 1 of 13 attempts on 1.15.0).
  • is_misfired is cleared anyway, so the record of the missed run is lost.

✅ Expected Result
  • Each misfired active job runs once on resume, then is_misfired is cleared.

ℹ️ Notes
  • Reproduced on 1.15.0 (bootJar, Postgres). The vetoer read next_run_time about 0.6 s after it was saved.

🔧 Technical Notes
  • JobRegisterServiceImpl#startScheduler: executeJob(..., TRIGGER_TYPE_CRON) (:175) only queues the fire via scheduler.triggerJob (:122). The same thread then sets jobDetail.setNextRunTime(trigger.getNextFireTime()) (:187) and saves it.
  • SchedularWritePlatformServiceJpaRepositoryImpl#processJobDetailForExecution (:146-150) vetoes a CRON-type fire when getNextRunTime().after(new Date()).
  • Fix idea: do not advance next_run_time before the replay has claimed the job, or replay with a trigger type that is not compared against next_run_time.
─────────────────────────────────────



--
This message was sent by Atlassian Jira
(v8.20.10#820010)