fix(cron): avoid recomputeNextRuns on forceReload#9393
fix(cron): avoid recomputeNextRuns on forceReload#9393matthewpapa07 wants to merge 1 commit intoopenclaw:mainfrom
Conversation
|
some cronjobs were broken for me. this patch fixes them. Took a while to find this because my bot kept hallucinating that cron was working |
f5729b8 to
70f0ed6
Compare
|
Tested locally — this fix works! Was hitting the exact bug described in #10269 where cron jobs would never execute. Applied this patch to both bundled JS files ( Both systemEvent and agentTurn jobs now fire correctly. Would love to see this merged! 🙏 |
|
Also fixes #10439 (cron scheduler not executing jobs after gateway restart). |
ducminhn
left a comment
There was a problem hiding this comment.
This PR fixes issue with cron jobs.
bfc1ccb to
f92900f
Compare
|
This pull request has been automatically marked as stale due to inactivity. |
|
This has been superseded in main and the latest releases. we can close |
Fixes cron timer never running jobs by skipping recomputeNextRuns on forceReload. When forceReload is used each tick, recomputeNextRuns advanced nextRunAtMs into the future, so dueCount stayed 0 forever.
Greptile Overview
Greptile Summary
This PR changes
src/cron/service/store.tsto skiprecomputeNextRuns(state)whenensureLoaded()is called with{ forceReload: true }. This aligns with the timer loop insrc/cron/service/timer.ts, which force-reloads the cron store on every tick before callingrunDueJobs(). The intent is to preventrecomputeNextRunsfrom continually advancingjob.state.nextRunAtMsduring repeated force reloads, which could otherwise keep jobs from ever becoming due.Confidence Score: 5/5
recomputeNextRunsthat only affects the{ forceReload: true }path used by the timer tick; it prevents a confirmed starvation mode without changing job execution or persistence logic.(2/5) Greptile learns from your feedback when you react with thumbs up/down!