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

[Shubham Chaudhary (Jira)]

    [ 
https://issues.apache.org/jira/browse/FINERACT-2918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129517#comment-18129517
 ] 

Shubham Chaudhary commented on FINERACT-2918:
---------------------------------------------

Hi [~adamsaghy] ,

I noticed that Mr. [~arnold]  has opened several issues, and I wanted to check 
whether he plans to work on all of them himself or if some of them are 
available for others to pick up.

I’ve already asked about a few of them in the comments but haven’t received a 
response yet. I’d be happy to take ownership of some issues and contribute to 
getting them resolved.

Please let me know if there are any I can work on.

> 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
>
> 📋 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)