galovics commented on code in PR #6726:
URL: https://github.com/apache/fineract/pull/6726#discussion_r4359171639


##########
fineract-provider/src/main/java/org/apache/fineract/infrastructure/jobs/service/JobRegisterServiceImpl.java:
##########
@@ -171,15 +167,19 @@ public void startScheduler() {
         if (schedulerDetail.isSuspended()) {
             schedulerDetail.setSuspended(false);
             
this.schedularWritePlatformService.updateSchedulerDetail(schedulerDetail);
-            if (fineractProperties.getJob().isExecuteMissedRuns()) {
-                replayMissedRuns();
-            } else if (schedulerDetail.isExecuteInstructionForMisfiredJobs()) {
+            if (schedulerDetail.isExecuteInstructionForMisfiredJobs()) {
                 final List<ScheduledJobDetail> scheduledJobDetails = 
this.schedularWritePlatformService
                         .retrieveAllJobs(fineractProperties.getNodeId());
                 for (final ScheduledJobDetail jobDetail : scheduledJobDetails) 
{
                     if (jobDetail.isTriggerMisfired()) {
                         if (jobDetail.isActiveSchedular()) {
-                            executeJob(jobDetail, 
SchedulerServiceConstants.TRIGGER_TYPE_CRON, Collections.emptySet());
+                            // Fire the misfire replay as an "application" 
trigger (same type used by the manual
+                            // /jobs/{id}?command=executeJob API), not "cron": 
processJobDetailForExecution() vetoes a
+                            // "cron" fire whose nextRunTime is in the future, 
and nextRunTime is advanced to the future
+                            // by this very method right below, racing the 
async veto check on another thread. A
+                            // non-cron trigger type bypasses that specific 
veto condition without weakening it for
+                            // genuinely-not-due cron fires.
+                            executeJob(jobDetail, 
SchedulerServiceConstants.TRIGGER_TYPE_APPLICATION, Collections.emptySet());

Review Comment:
   Agreed - already addressed on the latest push: added 
`SchedulerServiceConstants.TRIGGER_TYPE_MISFIRE = "misfire"` and the replay now 
fires with that instead of reusing `TRIGGER_TYPE_APPLICATION`, so a misfire 
replay is distinguishable from a manual `/jobs/{id}?command=executeJob` run in 
job history. Also strengthened the existing 
`resumeKeepsTheLegacyMisfiredReplayWhenDisabled` test to assert the replay 
actually executes (verified against the real in-memory Quartz fixture - 4/4 
tests pass).
   
   _🤖 Addressed by [Claude Code](https://claude.com/claude-code)_



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to