[
https://issues.apache.org/jira/browse/FINERACT-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnold Galovics updated FINERACT-2918:
--------------------------------------
Fix Version/s: 1.17.0
> 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
> Priority: Major
> Fix For: 1.17.0
>
>
> 📋 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
(v10.3.26#10030026)
