fix(cron): don't silently disable recurring cron jobs when croniter is missing#16368
Merged
Conversation
…s missing If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes #16265
Contributor
🚨 CRITICAL Supply Chain Risk DetectedThis PR contains a pattern that has been used in real supply chain attacks. A maintainer must review the flagged code carefully before merging. 🚨 CRITICAL: Install-hook file added or modifiedThese files can execute code during package installation or interpreter startup. Files: Scanner only fires on high-signal indicators: .pth files, base64+exec/eval combos, subprocess with encoded commands, or install-hook files. Low-signal warnings were removed intentionally — if you're seeing this comment, the finding is worth inspecting. |
negaterium
pushed a commit
to negaterium/hermes-agent
that referenced
this pull request
Apr 27, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265 (cherry picked from commit 7c63c24)
cluricaun28
referenced
this pull request
in cluricaun28/Logos
Apr 28, 2026
…s missing (#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes #16265
This was referenced Apr 29, 2026
ulasbilgen
pushed a commit
to ulasbilgen/hermes-adhd-agent
that referenced
this pull request
May 1, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
donald131
pushed a commit
to donald131/hermes-agent
that referenced
this pull request
May 2, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
02356abc
pushed a commit
to 02356abc/hermes-agent
that referenced
this pull request
May 14, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
dannyJ848
pushed a commit
to dannyJ848/hermes-agent
that referenced
this pull request
May 17, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
gweeteve
pushed a commit
to gweeteve/hermes-agent
that referenced
this pull request
Jun 2, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
Egavasyug
pushed a commit
to Egavasyug/hermes-agent
that referenced
this pull request
Jun 10, 2026
…s missing (NousResearch#16368) If the gateway's Python env loses access to 'croniter' between when a cron job was created and when mark_job_run() fires, compute_next_run() returns None for cron schedules. mark_job_run() treated that as terminal completion and wrote enabled=false, state=completed — turning a missing runtime dep into a silent, permanent job-off. That behaviour is safe for one-shot jobs but wrong for recurring ones. A missing dep should surface as an error the user can see, not as successful completion of a job that is about to stop firing. mark_job_run() now only disables the job on next_run_at=None when the schedule is one-shot. For recurring (cron/interval) schedules it keeps enabled=true, sets state=error, and records last_error so the user can see why the job isn't advancing. compute_next_run() also logs a warning the first time cron+no-croniter hits, so the underlying cause is visible in the gateway log. Tests cover: - recurring cron job stays enabled with state=error when HAS_CRONITER=False - recurring interval stays enabled when compute_next_run returns None - one-shot jobs still flip to enabled=false, state=completed (no regression) Fixes NousResearch#16265
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Recurring cron jobs no longer flip to
enabled=false, state="completed"when the gateway's Python env is missingcroniter. A missing runtime dep now surfaces asstate="error"withlast_errorset, and the job stays enabled.Root cause:
compute_next_run()returnsNonefor cron schedules whenHAS_CRONITER=False;mark_job_run()treated that as terminal one-shot completion and disabled the job. Safe for one-shots, destructive for recurring cron.Closes #16265.
Changes
cron/jobs.pymark_job_run(): only disable onnext_run_at=Nonefor one-shot schedules. For recurring (cron/interval), keepenabled=true, setstate="error", populatelast_errorwith a clear dep hint. Log an error when this path fires.cron/jobs.pycompute_next_run(): log a warning when a cron schedule hits the no-croniter branch, so the underlying cause is visible in the gateway log instead of silently returningNone.tests/cron/test_jobs.py: three new regression tests covering the recurring-cron, recurring-interval, and one-shot branches.Validation
enabled=false, state=completedenabled=true, state=error, last_error="...croniter..."enabled=false, state=completedenabled=true, state=errorenabled=false, state=completedenabled=false, state=completed(unchanged)E2E-tested by creating a real cron job, flipping
HAS_CRONITER=False, and callingmark_job_run— job stayed enabled with the expected error state.tests/cron/= 252 passed.